Chris,
On Fri, Apr 19, 2024 at 4:40 AM Christopher Schultz
<ch...@christopherschultz.net> wrote:
>
> 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?
In this instance, I meant the actual problems with the HTTP protocol contents.
400 is normally returned by the container because it couldn't
understand the HTTP.
414 is probably as well (because container ran out of maximum
available space to read
in the URI). The rest of the error codes are expected to be produced by the
application, but they were devised for that application being a web server.
> 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*.
Yes. But (again, assuming web-service-like implementation), the application can
return other HTTP codes for other data (on top of HTTP) issues, i.e., when an
endpoint is not found, 404, when data type is wrong - 415; there are also those
exuberant codes like 409 and 410. So, on the surface, it looks like
the application
can use 4xx codes to signal an error, so one can lay down a contract that says
"2xx means OK response from the application's perspective, and if there is an
error, we'll return some 4xx code", but there *was* (see below) no good 4xx
code for saying "Hey, you forgot a JSON property in your input".
You're right, it probably should have been 2xx, but it's also cringy
to say things like
"there are some errors that we will return 4xx for, but for some it will be 2xx,
and here is how you differentiate successful 2xx from error response 2xx".
I did do that in at least one w/s implementation, and had the customer
yell at me for my trouble. This path is also not well supported by standards
like OAS/RAML (last time I checked, at least). The description of the responses
becomes significantly more complicated in this case.
And, again, there is AWS that is a rather large supplier of web services,
and they did decide to use 400 for this. The web-service client still needs
to distinguish between "400 because the header is mangled", or "400 because
a JSON property was missing". The RFC doesn't explicitly limit the use of
400 to HTTP protocol problems, even though all the examples that are listed
in the spec *are* such.
I did look again at the specs just now, and lo and behold, there is now a
code 422. Which, at least on the surface, looks like exactly the code to use
for responding with application-related content problems. It wasn't there in
RFC#7231 (and neither in #2616 or #2068), but #9110 does have it (yet
the language around 400 is still overly broad), which makes it about 2
years old.
Now, of course, existing w/s contracts aren't likely to switch to using that,
but for any new ones I'll certainly consider it.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
