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
