https://bz.apache.org/bugzilla/show_bug.cgi?id=61090
--- Comment #23 from Yann Ylavic <ylavic....@gmail.com> --- Actually I (still) don't understand why this isn't the exact use case for the 100 continue mechanism. When the framing of the message ([1]) is not fulfilled there is no reliable way to communicate in HTTP. So if the origin server closes the connection with no respect to the framing, a proxy/gateway cannot figure out whether this is legit or not, not to talk about the inherently racy handling of such situation with regard to the transport (TCP). In the RFC(s) at least, there is no such thing as "the server can early close the connection" (besides the 100 continue mechanism). If mod_proxy were to handle an early response potentially followed by a close, how would it know whether it needs to send the rest of the request body or not? Depends on what? Can't the origin server start to respond early (say with the header) and then send the body later as the rest of the request arrives? How much should mod_proxy wait in this case before sending the rest of the request? So it looks like mod_proxy needs to either read the early response fully (and risk to block indefinitely if the origin waits for the rest too), or mod_proxy should continue sending the request until it receives the full response (and by doing that, if not before already, it may get a TCP reset at which point even if the response has been fully sent by the origin server there is no chance that it'll be received by mod_proxy). That's all racy.. Now there is the well defined and unracy 100 continue mechanism, where mod_proxy sends the request header (ping) and waits for a response. If the response is not a 100 continue then it's sent directly to the user-agent. No overhead, besides possibly a smaller first TCP buffer. If the response is 100 continue, things continue.. Small overhead for the interim response (pong) plus the smaller TCP buffer still. When the connections are reused between mod_proxy and the origin server, I don't think that the overhead is that noticeable. It certainly does not explain your results with ping= from comment 14, there is probably something else going on there. If curl sends 16K and tries to read the response (how long?) before sending the rest, I don't see how the above 100 continue mechanism between mod_proxy and the origin server (only) changes the timings/behaviour compared to a direct connection to the server. When curl handles an early response, does it close the connection immediately afterwards or does it continue to send the request body until the connection is closed/reset remotely? Could you please make the same test with the httpd-2.4.x branch, no spooling (resource filter..), to figure out what happens exactly? [1] https://tools.ietf.org/html/draft-ietf-httpbis-semantics-14#section-6.1 -- 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
