Re: 100 continue expectation with HTTP/2

On Fri, Dec 8, 2023 at 7:33 PM Greg Wilkins <gregw@webtide.com> wrote:

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

A non-100 response should be treated the same way as early responses for
normal requests. This was discussed during http-core reviews.

Reading the three specs quoted here, it seems that
1) server is required to signal to the client whether the request
should continue via connection-close in h1 and reset(no_error) in h2/h3
2) the h2 spec probably should say the same as the h3 spec wrt 1)
3) to Greg's last question, the client should wait for the server's
reset(no_error), unless applications want to abort the request

- Wenbo




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