https://bz.apache.org/bugzilla/show_bug.cgi?id=63855
--- Comment #22 from Michael Osipov <micha...@apache.org> --- (In reply to Yann Ylavic from comment #21) > > 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.. Aha thanks, so to sum up: * If no filter is in place the request will be passed as-is to the upstream server, regardless whether it is with CL or chunked. Omitting CL (convert to chunks) in this case would mean that a upstream server is not able to reject a potentionally to large request body in advance. * If a filter is in place and the client has sent a CL, mod_proxy will spool into memory/on disk, and depending on the filter either send chunks or have a modified CL to send to the backend. Is that correct? -- 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
