You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by "Jeremy Stashewsky (JIRA)" <ji...@apache.org> on 2012/07/27 23:48:33 UTC

[jira] [Commented] (TS-1384) SSL client fails to send response to origin server

    [ https://issues.apache.org/jira/browse/TS-1384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13424172#comment-13424172 ] 

Jeremy Stashewsky commented on TS-1384:
---------------------------------------

Forcing a writeReschedule() call when the object is for a client seems to fix the problem, but I haven't studied the code enough to know if this is the right solution (it *seems* to work, though).  Going to try tidy up a patch and get managerial approval to do so.
                
> 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
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira