> Assuming it's easy for Tomcat to differentiate between errors generated
My PR was based on the assumption that it is easy, since Tomcat always invokes this method[1] if it's a badRequest. [1] https://github.com/apache/tomcat/blob/main/java/org/apache/coyote/http11/Http11Processor.java#L849-L850 On Wed, Apr 24, 2024 at 11:51 AM Christopher Schultz < ch...@christopherschultz.net> wrote: > Stefan, > > On 4/24/24 13:58, Stefan Ansing wrote: > > 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? > > Assuming it's easy for Tomcat to differentiate between errors generated > by Tomcat (e.g. "real" 400 responses) and those generated by the > application, I think this is a good idea. HTTP 400 indicates a protocol > error, but if the application is generating it, then Tomcat need not > close the connection. > > Theoretically this could also be true for other status codes as well. I > chose 400 because it means the connection MUST be closed for security if > Tomcat is the one detecting that there is actually an HTTP protocol > violation. > > -chris > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
