https://bz.apache.org/bugzilla/show_bug.cgi?id=63855
--- Comment #21 from Yann Ylavic <ylavic....@gmail.com> --- > For my understand: This only happens when a body modifying filter is in > place?! Right. > The filter requires the body to be present in a streaming fashion to > perform its work, but "Expect: 100-continue" operates on the request headers > only and that is why HTTPd has never send the header to Tomcat and > everything stalled? So the filter should only happen when the downstream > server is willing to accept the request at all based on the headers. For mod_proxy to send/forward a body with Content-Length to the backend, it needs to known the actual size of the body. If some filter in the input chain potentially modifies the body in flight (any resource level filter), mod_proxy can't trust the original Content-Length send by the client so it can't steam the request body, it needs to spool/bufferize the body to determine the final length. The issue was that in this case plus 100-continue asked by the client, mod_proxy wasn't sending the "100 continue" interim response to the client before starting to read/spool the body, so mod_proxy and the client were waiting for each other. So yes having to spool the request breaks the purpose of end-to-end 100 continue, but there is no other choice when a resource input filter is configured AND a Content-Length has to be provided to the backend. The default/legacy for mod_proxy is to send a body with Content-Length (for default interoperability with servers don't handle Transfer-Encoding chunked). If the body is not streamable, that means spooling, and this now works with 100-continue too. To avoid spooling, one has to change the default by allowing chunked Transfer-Encoding (i.e. SetEnv proxy-sendchunks). This has been changed in 2.5+ where the default will be to use streaming/chunks (unless proxy-sendcl), but not in 2.4.x for compatibility reasons.. -- 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
