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


On Mon, Sep 25, 2023 at 02:25:52AM +0100, Lucas Pardue wrote:
> > 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.
> For the content-length matter I mentioned above, my implementation
> generates a 4xx in H2 and H3. I don't plan to change that.

I would say that it depends what can still be trusted:
  - if the stream sent a request that doesn't violate the stream's state
    but could cause havoc when passing the message to the other side (e.g.
    a content-length error), 4xx is perfectly fine because the stream's
    state is not altered, it's just that it could be dangerous to pass it
    to another host or an upper layer ;

  - if the stream contents are invalid and the stream cannot be converted
    into a parsable HTTP message (e.g. an empty HEADERS frame, or DATA
    frame immediately following an 1xx response HEADERS frame), it seems
    safer to me to reset it, at least because some of the rules that
    depend on the method or some pseudo-headers cannot be verified. But
    it may depend on the implementation. For example an implementation
    that is capable of sending a 4xx at the H2 layer might possibly do it,
    but one that needs to escalate to an application layer to produce a
    nicer contextual error message might have difficulties doing so and
    would rather produce a RST_STREAM. At this point it's better not to
    break the connection if possible, because these streams might have
    been passed through an intermediary by another agent without the
    intermediary being able to verify the details.

  - if the contents violate the connection state, at some point it might
    be impossible to save the connection. For example, receiving two
    HEADERS frame means that that there could be a doubt on the HPACK
    state, hence the ability to successfully decode subsequent HEADERS 
    frame might be impacted. In this case it might be better to kill
    the connection.

Overall I would suggest that an H2 (or even HTTP) implementation should
report at the highest possible level which doesn't compromise the lower
ones. This is the best way to report useful information to the user
without taking risks. And clearly these choices will often depend on
the implementation because not all will be able to act at an upper
layer and might be forced to be stricter than necessary.

Just my two cents,

Received on Monday, 25 September 2023 02:24:12 UTC