httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joachim Achtzehnter <joac...@kraut.ca>
Subject Re: HTTPS connections lock-up with 2.4.18
Date Wed, 03 Feb 2016 09:14:17 GMT
Late at night here and I'm not at work, but see the embedded responses 
to clarify some things...

On 2016-02-03 12:43 AM, Yann Ylavic wrote:
> On Wed, Feb 3, 2016 at 6:31 AM, Joachim Achtzehnter <joachim@kraut.ca> wrote:
>>
>> Attached is file "ssl_log-v3.txt" with the log messages seen when using your
>> v3 patch. The other two files are the corresponding Wireshark traces,
>> collected on the client-side where Firefox was trying to retrieve the file.
>
> Looks OK on the httpd side now with explicit flushes on write (during
> handshake), but the issue seems to be on the client side now.
>
> The "Encrypted Handshake Message" it uses to finalize its handshake
> looks really weird, and it doesn't wait for the server to finalize the
> handshake before sending the HTTP request (the complete handshake
> response will only be read by the client when it expects the HTTP
> response).
>
> I can't tell about the underlying HTTP data here, but I suspect there
> is more than a single HTTP request sent by the client,

No, there is definitely only one request for this test. In the real 
application there is an HTML page, which triggers multiple requests for 
style sheets, scripts, images, etc., and these may well be pipelined or 
submitted via parallel connections. This still locked-up, 100% 
reproducible. The test I use to collect the traces and logs is 
retrieving a single small style sheet. No other files are involved. In 
order to allow Wireshark to decrypt the SSL data I used Firefox, but for 
my own testing and debugging I usually submit the request with curl. The 
outcome is the same with both Firefox and curl.

> which makes httpd believe requests are pipelined,

How does it make this determination?

> and hence never  flush its output
> until the client stops pipelining requests.
> The client is now blocked waiting for the first response...

Yes, it is waiting forever.

> Before 2.4.18, since simply reading on the connection flushed the
> output data on the server side, the client had its response while the
> server was reading the second (pipelined) request.

Except that in this test there is no second request.

Some more details: The application offer the exact same Web 
functionality in one of two modes:

1) HTTP only, configuration does not use virtual hosts

2) HTTPS with HTTP redirected to the corresponding HTTPS URL. The exact 
same functionality as above is now defined in a virtual host for port 
number 443. The virtual host for port number 80 simply sends a redirect 
response back to the client.

With Apache 2.4.12 this all works. After upgrading to 2.4.18 mode 1 
still works perfectly, but with mode 2 some https requests never get a 
response and the application stalls.

> I'd need more info to confirm (or invalidate) this, like LogLevel
> trace8 (possibly privately, still).
>
>>
>> While exploring a final fix for this, can I ask for your opinion about the
>> following work-around we currently rely on until there is an official fix.
>> We continue to use Apache 2.4.18, but have replaced mod_ssl.so with the one
>> from Apache 2.4.12. Is this likely to be safe? or do you not recommend
>> mixing versions?
>
> This looks "risky" to me, recompiling 2.4.18 with your original patch
> is much better IMHO.

Thanks,

Joachim


> Regards,
> Yann.
>

Mime
View raw message