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:joac...@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
<joac...@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.
--
joac...@kraut.ca http://www.kraut.ca
