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:59:02 GMT
What is the size of /css/subpage.css?

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