Clarify about early responses (again)

[wenbozhu]

With HTTP/1.1 the common assumption is that error responses are allowed before the request is completed.

With HTTP/2, the spec seems to suggest that 2xx responses are also allowed before the request is completed, as long as the server doesn't care about the rest of response. This makes sense, if one considers the status representing the causal result of the server seeing all the received request data (but incomplete).

I believe this issue belongs to http-semantics.

===

I can live with the HTTP/2 interpretation.

It will be useful to spec out how proxies may behave, e.g. what to do with request data that arrives after the status has been received?

[wenbozhu]

Also, as I am adding 100-continue support for our c++ frontends, I noticed that early 2xx/3xx responses need be supported, as mentioned on https://tools.ietf.org/html/rfc7231#section-5.1.1

This is consistent with the http/2 interpretation, i.e. once the status is out, request body needs be discarded.

"
A server that responds with a final status code before reading the
entire message body SHOULD indicate in that response whether it
intends to close the connection or continue reading and discarding
the request message (see Section 6.6 of [RFC7230]).
"

[martinthomson]

You don't have to discard the request body, you have to indicate whether you intend to continue consuming it, or whether it should be discarded. That's an important difference. (QUIC decouples these properly, of course.)

[wenbozhu]

To me, "don't have to" is runtime behavior .. .or is this what you meant?

Re: the wire semantics, the way I read what the spec says is that, after the status header is generated, the rest of request body is "useless", e.g. a proxy may discard it if the client keeps sending it.

If this is not the case, what is the mechanism to indicate to the client that the server intends to continue consuming the request body, e.g. by not "finishing" the response?

The paragraph I copied from 100-continue sections is for http/1.1 connection keep-alive as I understand. Otherwise, it is asking the runtime to discard the request body.

[mnot]

I think we can move this forward by:

• Rewording that text in 8.1.1 Expect to remove the implication that the server has to discard if it sends a response (and also adjust for the fact that in H2 and later, you're talking about a stream, not the whole connection)
• Explicitly define the message ordering possibilities in 2.1 Client/Server Messaging

Anything else?

[royfielding]

But this isn't about semantics. The stuff about reading the request message body is due to message framing requirements in order to keep using the connection in HTTP/1.1. I think we just need to be sure the text is in the right place and then make it specific to 1.x.

[mnot]

I think it is about semantics; the ordering, overlap and cardinality of messaging in HTTP is important to applications that use the protocol.

[royfielding]

The larger issue is about semantics. The comment I am responding to is about rewording the 1.1-specific text about needing to read a request body from the connection if it intends to look for a next request on that connection (a practical matter that has no semantic significance). There is no need to make that generic.

AFAICT, I don't see any need for changes due to this issue because it is expressing a hypothetical and accepting the only result possible (the client gets a response and has no choice but to accept it as the server's response to their request, assuming it is either marked or associated by order as being the response.

[mnot]

OK, so you're referring to something previous? I didn't suggest changing anything in messaging.

[royfielding]

Yeah, I am just confused. I thought we were discussing the section in Messaging referred to by that bullet in Expect. Changing the bullet to "reading (and possibly discarding)" is one solution, or we can just rewrite the end of the bullet:

• A server that responds with a final status code before reading the entire message body SHOULD indicate in that response whether it intends to close the connection or continue reading and discarding the request message (see Section 9.6 of [Messaging]).

to be

• A server that responds with a final status code before reading the entire request payload body SHOULD indicate whether it intends to close the connection (see Section 9.6 of [Messaging]) or continue reading the payload body.

[mnot]

Fine with that. I still think that 2.1 needs to be more explicit; will do a PR.