Re: Can servers generate responses to malformed requests in h2?

Hey,

On Mon, 25 Sept 2023, 02:13 Martin Thomson, <mt@lowentropy.net> wrote:

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

I'm not saying it is. To give a different example,  there are rules around
treating requests with content as malformed if the content-length
mismatches sum of DATA. It us debatable if this is a framing error or a
semantic error.

>
> 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 my experience, connection errors are the worst user feedback. The only
way to debug this is to interrupt an H2 or H3 expert and ask them to go
look at a pcap etc. (If the problem can even be reproduced). It also has a
huge collateral damage, which is IMO not an acceptable cost.


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

For the content-length matter I mentioned above, my implementation
generates a 4xx in H2 and H3. I don't plan to change that.

Cheers
Lucas

>