Re: Expect-continue mechanism clarification

> On Sep 8, 2015, at 2:39 PM, Piotr Kołaczkowski <> 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?
> 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?

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.


Received on Tuesday, 8 September 2015 16:44:40 UTC