On Thu, Apr 18, 2024 at 9:40 AM Adwait Kumar Singh <adwsi...@gmail.com> wrote: > > I'm not (yet) convinced distinguishing between those scenarios is always > > going to be possible. > I have a Tomcat patch which we use at work to do this, i.e always close the > connection if HTTP parsing fails but not if it's a user set status. I can > create a PR for feedback.
It can't be that straightforward though. The HTTP parsing can very well fail well past the point the application was invoked, and returned a status, during chunked request parsing. The server can't respond with another error though, as the headers are/can be committed, it has no recourse but to try to send them if possible, and then shutdown the connection. And handling incomplete body reads from the application is also going to be a nuisance that has to be dealt with. Tomcat will have to consume the remainder of the body without application doing so, which may not be desirable in all cases, and will require either an API change to be supported as being signalled by the application (here is my status, but PLEASE don't break the HTTP connection), or requiring the application to diligently consume the body till the end before returning service back to Tomcat, or having that as a configuration parameter. I actually don't know how Tomcat deals with bodies that aren't fully read by the app right now. I would very much like to know for sure. > > On Thu, Apr 18, 2024 at 8:42 AM Mark Thomas <ma...@apache.org> wrote: > > > 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
