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.
modssl_ssl_need_flush-v3.patch
Description: application/download
