Op do 18 apr 2024 om 17:42 schreef Mark Thomas <ma...@apache.org>: > 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. > > If the server is correctly handling that request to generate the > response, a 500 status doesn't seem right either. > > > > > 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. > > 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 > > Hi Mark,
I can see your point of view regarding the use of the status codes for application errors. Unfortunately the HTTP spec doesn't clearly differentiate the use of status codes for protocol or application errors. Which is probably why these status codes are now also commonly used for application errors. Tomcat (and other servlet containers) currently allow applications to set any status code, but with the current behaviour of Tomcat this leads to unexpected side effects for some status codes. This behaviour makes it so that Tomcat might not be fit for our purpose (Spring Boot services to services communications). I think the way to resolve that is to alter the behaviour in Tomcat to differentiate between protocol and application errors when using these status codes (and to make this behaviour potentially configurable). I also think that this change would benefit most users of Tomcat since the behaviour in this scenario is unnecessary. Would the Tomcat developers be willing to do that? Stefan
