[
https://issues.apache.org/jira/browse/TS-1384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uri Shachar resolved TS-1384.
-----------------------------
Resolution: Fixed
Assignee: Uri Shachar
Seems to work fine in 4.1.2 - looks like it was fixed during the SSL efforts in
3.3.X.
I'm marking this as resolved - please reopen if you encounter any further
difficulties with this functionality.
> SSL client fails to send response to origin server
> --------------------------------------------------
>
> Key: TS-1384
> URL: https://issues.apache.org/jira/browse/TS-1384
> Project: Traffic Server
> Issue Type: Bug
> Components: SSL
> Affects Versions: 3.2.0
> Environment: OSX 10.7 and SmartOS, OpenSSL 0.9.8r, 0.9.8q and 1.0.1c
> (although there maybe be other bugs affecting 0.9.8; could only get 1.0.1c
> working)
> Reporter: Jeremy Stashewsky
> Assignee: Uri Shachar
> Fix For: 6.0.0
>
>
> When attempting the following request through a forward-proxy configured ATS
> instance.
> GET https://encrypted.example.com/ HTTP/1.1
> Accept: text/html
> I expected a normal 200 response, but instead got a hang and eventual 502
> hangup (generated by ATS). The request from the client is sent over HTTP and
> is not a CONNECT tunnel.
> It seems that at the network level the SSL handshake from ATS to the origin
> server works fine, but that no discernible request packet is sent. Looking
> at the test HTTPS origin server I'm using, indeed no request arrives (and the
> handshake seems fine).
> I dug through the code and it appears that in SSLNetVConnection::net_read_io,
> once the ssl handshake completes, the code assumes that the logical next step
> is to attempt to read from the socket. While this is certainly true for an
> HTTPS server, it is the opposite required for an HTTPS *client*.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
