https://bz.apache.org/bugzilla/show_bug.cgi?id=63855
--- Comment #11 from Yann Ylavic <ylavic....@gmail.com> --- I meant the first request in "ho1.txt", not the one from your "openssl s_client". This first request in "ho1.txt" is sent with both the header and body at the same time (and by the way has no "Expect: 100-continue"). The full body is available to mod_proxy during prefetch, all nonblocking, which means that it can determine/adjust the Content-Length by itself if needed, and forward the request to the backend immediately. On the other hand, your "openssl s_client" request sends the HTTP header first, and waits before sending the body. In this case, before forwarding the request, mod_proxy will check whether the body could be modified internally, which would change the Content-Length, and if so (any content filter present in the filter chain) it will spool the body to disk to be able to forward the potentially new/correct Content-Length along with the new body. This can be tuned with e.g. proxy-sendchunks which frees mod_proxy from Content-Length constraint (but requires a chunk-compatible backend), and thus allows to forward the header immediately. Now comes "Expect: 100-continue". For this request you'd expect mod_proxy to not wait for the body since the client wants to wait for a "100 continue" before sending it. But in the spooling case mentioned above, mod_proxy still needs to have the full content to determine the C-L, and thus it must read the body by and for itself. What my patch fixes is that in this case mod_proxy now honors the "Expect: 100-continue" and sends the "100 Continue" response before starting to read/spool (otherwise the client and mod_proxy wait for each other). This is a case where 100-continue cannot be forwarded to (initiated by) the backend, the job must be done on the proxy side (for the client side at least, nothing prevents mod_proxy to have its own 100-continue negotiation with the backend). Hope this helps.. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
