Github user asfgit closed the pull request at:
https://github.com/apache/trafficserver/pull/242
---
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 asfgit closed the pull request at:
https://github.com/apache/trafficserver/pull/182
---
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 jacksontj commented on the pull request:
https://github.com/apache/trafficserver/pull/242#issuecomment-119399795
From some chats with @SolidWallOfCode the issue he saw may have been due to
how he implemented the feature previously (at a higher layer)-- but we aren't
sure.
GitHub user jacksontj opened a pull request:
https://github.com/apache/trafficserver/pull/242
Add tests for TS-3725
This includes allowing loopback addresses in hosts files. @SolidWallOfCode
had some concerns, but from my testing I can't see any reason why we wouldn't
allow this he
Github user asfgit closed the pull request at:
https://github.com/apache/trafficserver/pull/229
---
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 ericcarlschwartz commented on the pull request:
https://github.com/apache/trafficserver/pull/194#issuecomment-119357789
@shinrich here's a proposed solution:
if TS_USE_TLS_SNI isn't set then we put the logic where you'd suggested. if
it is, we set the trace right a
Github user ericcarlschwartz commented on the pull request:
https://github.com/apache/trafficserver/pull/194#issuecomment-119345316
and for the non SNI-enabled case I can put it in the equivalent function in
the corresponding #else block
---
If your project is set up for it, you can
Github user ericcarlschwartz commented on the pull request:
https://github.com/apache/trafficserver/pull/194#issuecomment-119344998
@shinrich: did some testing there. the problem w/ putting it right in that
particular spot is that the return value from SSL_get_servername call will
alw
Github user ericcarlschwartz commented on the pull request:
https://github.com/apache/trafficserver/pull/194#issuecomment-119295104
Ah yes I remember that part of things in terms of what's stored where, was
just wondering how that worked exactly since the ssl_vc is in the faux
transac
Github user shinrich commented on the pull request:
https://github.com/apache/trafficserver/pull/194#issuecomment-119289670
For SPDY and H2 the underlying SSLNetVConnection is stored with the
SPDYClient and the Http2Client respectively. Multiple faux Http1.1
transactions are created
Github user ericcarlschwartz commented on the pull request:
https://github.com/apache/trafficserver/pull/194#issuecomment-119275969
@shinrich ah ok thanks for the comments. I'll make that first change today.
w.r.t. the second comment will have to think more about it. because we
Github user shinrich commented on the pull request:
https://github.com/apache/trafficserver/pull/194#issuecomment-119261713
The SNI name check looks better. A couple comments remaining.
computeSSLTrace() might be getting called more than once per transaction.
You are probabl
Github user shinrich commented on the pull request:
https://github.com/apache/trafficserver/pull/218#issuecomment-119238728
My only comment is about the limits of the client_* fields. As they stand,
they only accurately track HTTP/1.x over TCP/SSL, not requests over SPDY/H2. I
know
Github user shinrich commented on the pull request:
https://github.com/apache/trafficserver/pull/229#issuecomment-119236957
The changes look good to me. Please resolve the merge conflict, and I'll
get this committed.
---
If your project is set up for it, you can reply to this email
Github user shinrich commented on the pull request:
https://github.com/apache/trafficserver/pull/232#issuecomment-119234117
Two comments. One is a minor style comment about the functions you added
to SSLInternal.c. Ideally the API for the functions in there should be the
same as the
Github user asfgit closed the pull request at:
https://github.com/apache/trafficserver/pull/239
---
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 shinrich commented on the pull request:
https://github.com/apache/trafficserver/pull/241#issuecomment-119198776
Turns out no code change is needed. See comments on issue for details.
---
If your project is set up for it, you can reply to this email and have your
reply app
Github user shinrich closed the pull request at:
https://github.com/apache/trafficserver/pull/241
---
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
Github user shinrich commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/241#discussion_r34028929
--- Diff: iocore/net/SSLUtils.cc ---
@@ -308,8 +308,10 @@ set_context_cert(SSL *ssl)
if (ctx != NULL) {
SSL_set_SSL_CTX(ssl, ctx);
If you attach a transformation plugin the std::string will be populated
with whatever the body is, even if it's binary data. You'll need to use
.size()/.length() to determine the buffer size and then just make sure you
do not use string functions if it's binary data (check the content-type).
Brian
20 matches
Mail list logo
