Hi James,
> Each side would be a separate NetVConnection.
Yes, Each side is a separate NetVC and Socket FD, thus every side has
client and server.
for Client Side Context:
1. if no transparent enabled:
get_client_addr() = get_remote_addr() is client ip address.
get_server_addr() = get_local
Github user masaori335 commented on the pull request:
https://github.com/apache/trafficserver/pull/600#issuecomment-214095730
@shinrich Could you take a look?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your projec
GitHub user masaori335 opened a pull request:
https://github.com/apache/trafficserver/pull/600
TS-4355: Change assert condition for TS-3612
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/masaori335/trafficserver ts-4355
Alterna
Github user asfgit closed the pull request at:
https://github.com/apache/trafficserver/pull/547
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature
Github user jpeach commented on the pull request:
https://github.com/apache/trafficserver/pull/546#issuecomment-214077247
Closing as duplicate of #547.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does
The name change makes sense to me. I'll make the change everywhere in my PR
tomorrow if everyone agrees with it. To be clear:
- Method to create SSL server context: `TSSslServerContextCreate`
- Method to destroy any kind of SSL context: `TSSslContextDestroy`
On Sun, Apr 24, 2016 at 2:57 PM, James
This looks pretty reasonable to me. One concern I have is that this API creates
SSL server contexts, so we ought to distinguish that in the API name.
I propose that TSSslContextCreate() be named TSSslServerContextCreate(), and
that we define TSSslContextDestroy() will be able to destroy both ser
Github user jpeach commented on the pull request:
https://github.com/apache/trafficserver/pull/583#issuecomment-214042536
This looks good to me. I think it should be reasonable to construct a
simple integration test for this?
---
If your project is set up for it, you can reply to thi
Github user jpeach closed the pull request at:
https://github.com/apache/trafficserver/pull/402
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature
Github user jpeach commented on the pull request:
https://github.com/apache/trafficserver/pull/402#issuecomment-214042675
Closing in favor of #594.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not
Github user jpeach commented on the pull request:
https://github.com/apache/trafficserver/pull/571#issuecomment-214041833
Note to self: check what glibc does with ``optind=1``, which is the pattern
used by remap plugins.
---
If your project is set up for it, you can reply to this ema
Github user jpeach commented on the pull request:
https://github.com/apache/trafficserver/pull/593#issuecomment-214041764
Could you please remove these remaining references:
```
$ git grep traffic_sac
.gitignore:proxy/traffic_sac
doc/locale/ja/LC_MESSAGES/admin/working-l
Github user ushachar closed the pull request at:
https://github.com/apache/trafficserver/pull/599
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the featur
> On Apr 22, 2016, at 7:28 PM, Chao Xu wrote:
>
> As a proxy, there has two side: client side ( Client <-> Proxy ) and server
> side ( Proxy <-> Server ).
Each side would be a separate NetVConnection.
> Add a new member 'netvc_context' into class NetVConnection to indicate
> which side the Net
14 matches
Mail list logo
