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:20:09 GMT
On 2016-02-03 12:59 AM, Plüm, Rüdiger, Vodafone Group wrote:
> What is the size of /css/subpage.css?

It is fairly small, 1698 bytes to be exact. As I wrote in an earlier 
message, it seems that the problem happens with smaller files, but not 
with bigger files. Another file that fails consistently has a size of 
2509 bytes. Three files that work consistently are 3991, 6478, and 
1239621 bytes long, respectively. Might there be something special going 
on if the response, headers plus data, fits in a single bucket?

Thanks,

Joachim


> Regards
>
> Rüdiger
>
>> -----Original Message-----
>> From: Plüm, Rüdiger, Vodafone Group
>> Sent: Mittwoch, 3. Februar 2016 09:19
>> To: dev@httpd.apache.org
>> Subject: RE: HTTPS connections lock-up with 2.4.18
>>
>> What is the configuration of your https hosts? Do you have multiple name
>> based one? Did you enable mod_http2?
>>
>> Regards
>>
>> Rüdiger
>>
>>> -----Original Message-----
>>> From: Joachim Achtzehnter [mailto:joachim@kraut.ca]
>>> Sent: Mittwoch, 3. Februar 2016 06:31
>>> To: dev@httpd.apache.org
>>> Subject: Re: HTTPS connections lock-up with 2.4.18
>>>
>>> Hi Yann,
>>>
>>> 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.
>>>
>>> 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?
>>>
>>> Thanks,
>>>
>>> Joachim
>>>
>>>
>>>
>>> On 2016-02-02 4:46, Yann Ylavic wrote:
>>>> Back to the list...
>>>> (Attaching the logs provided privately by Joachim, with the client IP
>>>> - the only possible sensitive informatition - replaced with
>>>> XXX.XXX.XXX.XXX).
>>>>
>>>> On Tue, Feb 2, 2016 at 11:08 AM, Joachim Achtzehnter
>> <joachim@kraut.ca>
>>> wrote:
>>>>>
>>>>> Applied you patch, built, installed, and then tested. There was no
>>>>> improvement. I've attached the log messages as "ssl_log-v2.txt".
>>>>>
>>>>> The I changed "#if 0" to #if 1" and it is still not working. Th elog
>>>>> messages for this case are attached as "ssl_log-v2-if1.txt".
>>>>
>>>> These logs show that the flush on read is *not* necessary (at least
>>>> from mod_ssl POV), provided each write is flushed during handshake.
>>>> Unfortunately OpenSSL does not seem to do it by itself: there is no
>>>> "bio[%pp] out: FLUSH" outside implicit onces from
>>>> bio_filter_out_write().
>>>> So if the "#if 1" patch seems unnecessary, the "#if 0" one looks
>> needed.
>>>>
>>>>>
>>>>> So far, the only version that worked was the old approach, to always
>>> flush
>>>>> before blocking on the read.
>>>>
>>>> Everything is flushed (during handshake) with this new patch, however
>>>> we can't say anything about the HTTP response itself at the end of the
>>>> request (the flushes not initiated by mod_ssl are not logged with my
>>>> patch, nor LogLevel debug).
>>>> Attached is (yet) another patch which also outputs METADATA buckets
>>>> passing through mod_ssl, so that we can see whether the HTTP response
>>>> is finally flushed or not (there were other changes in 2.4.18
>>>> regarding this, i.e. in check_pipeline_flush).
>>>> A simultaneous network capture (pcap) would also be very valuable
>>>> (btw, where your previous capture taken from, on the server or client
>>>> side?).
>>>> This patch shouldn't make it work though, it's just more logging stuff
>>>> compared to the previous one, unless maybe you change the new "#if 0"
>>>> (elsewhere this time) to an "#if 1"?
>>>>
>>>> Thanks (again) for testing Joachim.
>>>>
>>>> Regards,
>>>> Yann.
>>>>
>>>
>>> --
>>> joachim@kraut.ca http://www.kraut.ca

Mime
View raw message