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: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
