Re: Suspected ambiguity in H1 around Expect: 100-continue

Section 7.5 of RFC9110 says:
A client that receives a response while it is still sending the associated request SHOULD continue sending that request unless it receives an explicit indication to the contrary (see, e.g., Section 9.5<https://httpwg.org/specs/rfc9112.html#persistent.failures> of [HTTP/1.1]<https://httpwg.org/specs/rfc9110.html#HTTP11> and Section 6.4<https://www.rfc-editor.org/rfc/rfc9113.html#section-6.4> of [HTTP/2]<https://httpwg.org/specs/rfc9110.html#HTTP2>).
Section 9.3 of RFC9112 says:
A server MUST read the entire request message body or close the connection after sending its response; otherwise, the remaining data on a persistent connection would be misinterpreted as the next request. Likewise, a client MUST read the entire response message body if it intends to reuse the same connection for a subsequent request.
Section 9.5 of RFC9112 says:
A client sending a message body SHOULD monitor the network connection for an error response while it is transmitting the request. If the client sees a response that indicates the server does not wish to receive the message body and is closing the connection, the client SHOULD immediately cease transmitting the body and close its side of the connection.
Servers MUST either eat the entire body or close the connection; if the server has told you it doesn't want the body, the latter implies that a server will probably be closing the connection, but the client SHOULD do so immediately whether the server does or not.

I think what's missing is a second sentence in the first quote which says if the client doesn't continue sending the request, it MUST close the connection.
________________________________
From: Willy Tarreau <w@1wt.eu>
Sent: Thursday, August 7, 2025 1:21 AM
To: Sean McArthur <sean@seanmonstar.com>
Cc: Glenn Strauss <gs-lists-ietf-http-wg@gluelogic.com>; HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: Suspected ambiguity in H1 around Expect: 100-continue

On Wed, Aug 06, 2025 at 07:26:46PM -0400, Sean McArthur wrote:
> Actually this specific gotcha did come up a while ago with hyper and curl.
> As I read our comments again, we identified the same ambiguity.
> Specifically how a client should retry without the header, but skipping
> sending the body, on the same connection.
> https://github.com/hyperium/hyper/issues/2791

Indeed, that's exactly what I had in mind!

> hyper still decided that as long as there was a content-length header, the
> payload is either expected or a conn should be closed. (In my mind, it
> could be request smuggling to treat it as a new request.)

I totally agree. Normally the header is pretty clear about this (and I
also agree that with chunked encoding it would be possible to just send
0 CRLF CRLF and start a new request). But the wording of the spec leaves
the door open to misinterpretation. I'd personally have added a warning
in an extra sentence to remind that the receipt of a complete response
doesn't terminate the request message and that the client must either
finish the upload or close the connection.

> I don't know if curl treats it differently.
>
> But yes, the confusion has happened before.

Thanks for confirming my doubts ;-)

Willy