httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Plüm, Rüdiger, Vodafone Group <ruediger.pl...@vodafone.com>
Subject RE: HTTPS connections lock-up with 2.4.18
Date Wed, 03 Feb 2016 08:18:58 GMT
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