Re: 100 continue expectation with HTTP/2

Lucas, Amos,

Thanks for those insights.    Our h2 implementation was not doing that, but
it makes sense to send a reset(NO_ERROR) after the response content.

But now, I'm wondering what the client side should do after it has sent a
request with 100 expectation, but received a non-100 response?
Should it too send a reset(NO_ERROR), or should it wait, expecting the
server's reset(NO_ERROR)?   I'm guessing the former is less fragile.

regards







On Sat, 2 Dec 2023 at 07:35, Amos Jeffries <squid3@treenet.co.nz> wrote:

> On 1/12/23 13:36, Greg Wilkins wrote:
> >
> > Hi,
> >
> > I can't find a clear statement of how a H2 client should behave when it
> > has sent a request containing an 100 Continue expectation, but that
> > receives a response other than a 100.
> >
> > In RFC9110 10.1.1 Expect
> > <https://httpwg.org/specs/rfc9110.html#field.expect> it only says:
> >
> >       * A server that responds with a final status code before reading
> >         the entire request content /SHOULD/ indicate whether it intends
> >         to close the connection (e.g., see Section 9.6
> >         <https://httpwg.org/specs/rfc9112.html#persistent.tear-down> of
> >         [HTTP/1.1] <https://httpwg.org/specs/rfc9110.html#HTTP11>) or
> >         continue reading the request content.
> >
> > So there is an example of how a HTTP/1.1 server should behave (close the
> > connection after sending the response).
> >
> > But I can find no such statement regarding H2, which does not use a
> > Connection: close header and thus has no way of indicating if the server
> > intends to read the request content or not.
> >
>
>
> RFC9110 requirements apply to all (current) HTTP versions. The lack of
> specific text overriding the above in RFC9113 means it applies to HTTP/2
> even though the example is for HTTP/1.1.
>
> Notice that the requirement is not dependent on the "Connection:close"
> header. Also, that the stream would always be closed under HTTP/2
> transaction semantics.
>
> So IMO, the 100-continue and lack of 100 status can essentially be
> ignored by HTTP/2 agents. The client expectation is *always* that the
> connection remains open and stream closes.
>
>
>
> >  Should the client reset the
> > stream?  Or should the server reset the stream after sending the
> response?
>
>
> Good question. Either can do it?
>
>
> Cheers
> Amos
>
>

-- 
Greg Wilkins <gregw@webtide.com> CTO http://webtide.com