On Wed, Feb 3, 2016 at 6:31 AM, Joachim Achtzehnter <joac...@kraut.ca> wrote: > > 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.
Looks OK on the httpd side now with explicit flushes on write (during handshake), but the issue seems to be on the client side now. The "Encrypted Handshake Message" it uses to finalize its handshake looks really weird, and it doesn't wait for the server to finalize the handshake before sending the HTTP request (the complete handshake response will only be read by the client when it expects the HTTP response). I can't tell about the underlying HTTP data here, but I suspect there is more than a single HTTP request sent by the client, which makes httpd believe requests are pipelined, and hence never flush its output until the client stops pipelining requests. The client is now blocked waiting for the first response... Before 2.4.18, since simply reading on the connection flushed the output data on the server side, the client had its response while the server was reading the second (pipelined) request. I'd need more info to confirm (or invalidate) this, like LogLevel trace8 (possibly privately, still). > > 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? This looks "risky" to me, recompiling 2.4.18 with your original patch is much better IMHO. Regards, Yann.
