https://bz.apache.org/bugzilla/show_bug.cgi?id=61090
--- Comment #16 from Yann Ylavic <ylavic....@gmail.com> --- (In reply to Michael Osipov from comment #13) > First of all, the case here applies only to clients which do not provide > "Expect: 100-continue", e.g., py-requests. OK, so the ping= parameter allows 100-continue between mod_proxy and the backend only. > > > Also, I think that a backend should not allow itself to respond early and > > close the connection (without reading the whole request) unless 100-continue > > is involved somehow. ... > > Why actually? Tomcat does this and decent clients are able to handle it > (e.g., curl). Consider that I am uploading a huge payload and the server > knows after a few hundred bytes that it will refuse to process the request > anyway. Why waste time and bandwidth to reject the request after the upload? A proxy is not a client, there are cases where whatever the proxy does it can not recover from this situation. See below. > > I'd like to cite RFC 7230 which covers this case: Not really.. > > First: > > 6.3.1. Retrying Requests > > > > Connections can be closed at any time, with or without intention. > > Implementations ought to anticipate the need to recover from > > asynchronous close events. > > When an inbound connection is closed prematurely, a client MAY open a > > new connection and automatically retransmit an aborted sequence of > > requests if all of those requests have idempotent methods (Section > > 4.2.2 of [RFC7231]). A proxy MUST NOT automatically retry > > non-idempotent requests. So it's clearly a different situation for a CLIENT and a proxy above, right? But we are not talking about retrying requests here anyway. > > Second: > > 6.6. Tear-down > > > > A server that sends a "close" connection option MUST initiate a close > > of the connection (see below) after it sends the response containing > > "close". The server MUST NOT process any further requests received > > on that connection. The above says nothing about when the SERVER should close the TCP connection after sending a "Connection: close" response, and particularly nothing about _early_ "close" (read "Connection: close" when "close" is between double quotes). > > > > A client that receives a "close" connection option MUST cease sending > > requests on that connection and close the connection after reading > > the response message containing the "close"; if additional pipelined > > requests had been sent on the connection, the client SHOULD NOT > > assume that they will be processed by the server. That's not the same situation really, all this talks about is what a CLIENT/SERVER should do after a "Connection: close" request/response has completed. > > This is what is happening here. Tomcat closes the connection due to the 401, > but HTTPd still insists on sending the request body. What happens if Tomcat closes the connection as soon as it sends an early response it that there is no way for the proxy to reliably read the early response. Anything sent to Tomcat can reset the connection at the TCP level, at which point nothing can be read, including the eraly response. Suppose the proxy reads the client header and the first 16K of the body and forwards that to Tomcat, nothing garantees that Tomcat will get that header+16K in one piece. Suppose that Tomcat reads the header + 8K only, responds with 401 and closes the connection. The remaining 8K (in flight) will be reset by its TCP stack and now the connection is over for everyone. What can the proxy do to make this reliable? Send the header only, try to read the response with some timeout, forward the response if any, otherwise send the body. Sounds like an 100-continue right? Less efficient though because of the arbitrary timeout (avoided by 100 continue ack..). -- 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
