> > 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. 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 > >
