- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Sat, 2 Dec 2023 09:31:24 +1300
- To: ietf-http-wg@w3.org
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
Received on Friday, 1 December 2023 20:31:34 UTC