Subject: Expect-continue mechanism clarification

From: Piotr Kołaczkowski <[email-masked]>
Date: Tue, 8 Sep 2015 15:39:50 +0200

Hello Guys,

In HTTP/1.1, if the server gets a request with "Expect: 100-Continue" and,
after validation of the head of the message, it decides to respond with an
error status code (e.g. 4xx or 5xx) but it doesn't close the connection,
what state should it transition to? Should it wait for the rest of the body
(and discard it) or should it immediately reset back to the initial state
and wait for the next request in the sequence?

Also, on the client side - when the client receives a final response
instead of status 100 and decides not to close the connection, can it
immediately jump to sending the next request, or does it have to send the
remaining body?

One of the requirement says:

"Upon receiving a request which includes an Expect request-header
field with the "100-continue" expectation, an origin server MUST
either respond with 100 (Continue) status and continue to read
from the input stream, or respond with a final status code. The
origin server MUST NOT wait for the request body before sending
the 100 (Continue) response. If it responds with a final status
code, it MAY close the transport connection or it MAY continue
to read and discard the rest of the request.  It MUST NOT
perform the requested method if it returns a final status code"

which pushes me toward thinking that after sending the final status code,
if the server does not close the connection, the server would be still
waiting for the rest of the request (to be discarded), and must not move on
to processing the next request on the same connection until it gets the end
of the body (last chunk or all content-length bytes). Is it a correct
interpretation?

Thanks,
Piotr Kołaczkowski

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 8 Sep 2015 17:44:09 +0100

> On Sep 8, 2015, at 2:39 PM, Piotr Kołaczkowski <[email-masked]> wrote:
> 
> Hello Guys,
> 
> In HTTP/1.1, if the server gets a request with "Expect: 100-Continue" and, after validation of the head of the message, it decides to respond with an error status code (e.g. 4xx or 5xx) but it doesn't close the connection, what state should it transition to? Should it wait for the rest of the body (and discard it) or should it immediately reset back to the initial state and wait for the next request in the sequence?
> 
> Also, on the client side - when the client receives a final response instead of status 100 and decides not to close the connection, can it immediately jump to sending the next request, or does it have to send the remaining body?
> 
> which pushes me toward thinking that after sending the final status code, if the server does not close the connection, the server would be still waiting for the rest of the request (to be discarded), and must not move on to processing the next request on the same connection until it gets the end of the body (last chunk or all content-length bytes). Is it a correct interpretation?

Yes. Either side can choose to close the connection, but the server can't see another request until it has read past the framing of the first request. Most servers choose to close the connection if the response is non-2xx because 100-continue is meant to abort the send when it is unwanted.

....Roy