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

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

> On Mon, Sep 25, 2023, at 11:25, Lucas Pardue wrote:
> > For the content-length matter I mentioned above, my implementation
> > generates a 4xx in H2 and H3. I don't plan to change that.
>
> Content-Length has always been a bit of an awkward fit in the
> specification.  Maybe you are right to say that you want to signal that
> error at the HTTP layer, but would you say the same if you received a
> SETTINGS frame on a request stream or one of the many other errors
> specified in the RFC?
>

I wouldn't say the same. And perhaps this might sound frustrating because
it's inconsistent.

SETTINGS are their own thing. They are never part of an HTTP message,
although then can control aspects of how messages are handled or treated.

Use of status codes can also be inconsistent. For instance, if I'm an
intermediary and I try to forward a request but the origin isn't there, I
might return a 5xx error. Whereas if I can speak the the origin and get as
far as serving response header but then there is a problem, resetting the
stream is a very useful capability.


> It would be best if these sorts of divergences from what we specified were
> documented in the specification, don't you think?
>

I'm down for clarifying specifications if we can. But from some of the
replies on this thread, I'm not sure there's consistency. And so there's a
risk that we could go too far into trying to mandate changes to live
systems that can't change easily, because the collateral damage could be
too big and the feedback cycles too slow.

H2spec is a nice tool but it's scope is quite limited. I'd have more
confidence in spec adjustments after a broader survey like cache-tests.fyi

Cheers
Lucas

>