Pawel,
On 4/18/24 20:21, Pawel Veselov 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.
It's by now, however, a de-facto standard. Every time I try to
determine "which HTTP response should I send back in case of issues
with the data", I find myself scrolling through the list of defined
codes and not finding anything that would otherwise fit. The HTTP
spec states what should the server do in case of HTTP protocol errors
(respond with an appropriate 4xx), but that's all that the spec
covers for the protocol, and it doesn't prohibit use of 400 for
application-level errors. Out of the entire 4xx codes, 400 is (maybe
also 414?) the only one that is used for protocol problems, others
are for application level errors, but they are very specific and
limiting (IMHO).
When you say "protocol problems", what protocol are you referring to?
Because if the request is readable and syntactically correct, there is
no protocol problem. Everything else is ... something else. If you are
establishing a protocol ON TOP OF HTTP then it's a violation of whatever
protocol THAT is, not HTTP. So it's better to return { "error" : "Foo
Protocol violation" } with an appropriate HTTP status code, possibly
even *200*.
Then, how do I return error paths, when implementing things like a web service?
Either returning it with 200 and custom headers that indicate it's an
error response,
or a 400 with the same. In which case, the difference on the client side is -
does it have to logically differentiate valid response from an error based just
on these custom headers/mime type, or differentiate protocol-related 400 from
application-related 400, and can always treat 200 as proper.
Then I look at "what do others do", and I see AWS that uses 400 for all client
errors, and the way a client knows it's an application error is because there is
content that wouldn't be typically returned if there is a protocol problem.
So I follow suit.
If the server is correctly handling that request to generate the
response, a 500 status doesn't seem right either.
Right. 5xx - my fault, 4xx - your fault.
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.
I'd imagine it reasonable that as long as Tomcat doesn't find any issues
with the HTTP protocol itself - closing connections wouldn't serve any
helpful purpose in that case, except for not having to read the remainder
of the message. I'd like to know how the connection can be mucked up
otherwise, whether a proxy is involved or not.
If there is a proxy in the mix then the risks of something going wrong
tend to go up.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
