https://bz.apache.org/bugzilla/show_bug.cgi?id=65844
Ruediger Pluem <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #4 from Ruediger Pluem <[email protected]> --- I think we need to close the the connection in case the reverse proxy answers with a final response it got from the backend. See https://datatracker.ietf.org/doc/html/rfc7231#page-35: o A server that responds with a final status code before reading the entire message body SHOULD indicate in that response whether it intends to close the connection or continue reading and discarding the request message (see Section 6.6 of [RFC7230]). This should avoid request smuggling attacks as once we send the final response to the client we don't know if the next data send from the client is the request body for the previous request or a new request. This is because of o A client that sends a 100-continue expectation is not required to wait for any specific length of time; such a client MAY proceed to send the message body even if it has not yet received a response. Furthermore, since 100 (Continue) responses cannot be sent through an HTTP/1.0 intermediary, such a client SHOULD NOT wait for an indefinite period before sending the message body. at https://datatracker.ietf.org/doc/html/rfc7231#page-35. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
