httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yann Ylavic <>
Subject Re: HTTPS connections lock-up with 2.4.18
Date Tue, 02 Feb 2016 12:46:26 GMT
Back to the list...
(Attaching the logs provided privately by Joachim, with the client IP
- the only possible sensitive informatition - replaced with

On Tue, Feb 2, 2016 at 11:08 AM, Joachim Achtzehnter <> 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
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
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.


View raw message