- From: Martin Thomson <mt@lowentropy.net>
- Date: Mon, 25 Sep 2023 11:13:06 +1000
- To: "Lucas Pardue" <lucaspardue.24.7@gmail.com>
- Cc: "HTTP Working Group" <ietf-http-wg@w3.org>, "Matthew Davidson" <matthew@modulolotus.net>
On Mon, Sep 25, 2023, at 10:40, Lucas Pardue wrote: > My 2c: generating an HTTP error status suits the way that client-side > error detection and reporting works (paving cowpaths, yadayada). Stream > errors are not very well handled technically or non-technically. If the error occurs at the h2 framing layer and is detected at that layer, why is it difficult to generate an error at that same layer? How clients consume such errors is a very good point, and what seems to motivate Glenn's position also. I would argue that that points more toward a connection error than it does to 400. If there really is an error in the request, then a 400 risks burying the true error. > From an HTTP/3 perspective, it contains similar language mentioned > here. However, if I want to generate an error response and ensure that > it makes it to the client, I can't really reset the stream. Thanks for mentioning HTTP/3. I forgot to. The text is virtually identical there. The added text there adds some flavour: "Note that these requirements are intended to protect against several types of common attacks against HTTP; they are deliberately strict because being permissive can expose implementations to these vulnerabilities." > So I'd like to ask whether we can really effect change in the areas > discussed here, or if we should admit that the cows already bolted. I'm not sure that they have. My understanding is that most implementations generate the stream error, either because they test with h2spec or because they just do.
Received on Monday, 25 September 2023 01:13:32 UTC