> On 18/04/2024 15:18, Stefan Ansing wrote: > > Hi Rémy, Mark, > > I just want to make sure that we’re understanding each other. I can see > > that the connection needs to be closed in certain conditions to prevent > > request smuggling attacks. I certainly don’t want to change that behaviour. > > However, I’m facing a scenario where an application is responding to a > > valid request (from HTTP perspective), with a valid response using these > > status codes (more specifically status codes 400 and 500). > If the request is a valid HTTP request then a 400 status doesn't seem > appropriate to me.
It's by now, however, a de-facto standard. Every time I try to determine "which HTTP response should I send back in case of issues with the data", I find myself scrolling through the list of defined codes and not finding anything that would otherwise fit. The HTTP spec states what should the server do in case of HTTP protocol errors (respond with an appropriate 4xx), but that's all that the spec covers for the protocol, and it doesn't prohibit use of 400 for application-level errors. Out of the entire 4xx codes, 400 is (maybe also 414?) the only one that is used for protocol problems, others are for application level errors, but they are very specific and limiting (IMHO). Then, how do I return error paths, when implementing things like a web service? Either returning it with 200 and custom headers that indicate it's an error response, or a 400 with the same. In which case, the difference on the client side is - does it have to logically differentiate valid response from an error based just on these custom headers/mime type, or differentiate protocol-related 400 from application-related 400, and can always treat 200 as proper. Then I look at "what do others do", and I see AWS that uses 400 for all client errors, and the way a client knows it's an application error is because there is content that wouldn't be typically returned if there is a protocol problem. So I follow suit. > If the server is correctly handling that request to generate the > response, a 500 status doesn't seem right either. Right. 5xx - my fault, 4xx - your fault. > > I don’t think that in this scenario a request smuggling attack could be > > executed, or am I missing something? > The main issue is if the original request is invalid HTTP there is no > way to determine where the next HTTP request starts. I'd imagine it reasonable that as long as Tomcat doesn't find any issues with the HTTP protocol itself - closing connections wouldn't serve any helpful purpose in that case, except for not having to read the remainder of the message. I'd like to know how the connection can be mucked up otherwise, whether a proxy is involved or not. > > If there is a proxy in the mix then the risks of something going wrong > tend to go up. > > Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
