Opened 10 years ago

Closed 9 years ago

#467 closed design (fixed)

Expect/Continue and "final" status codes

Reported by: mnot@… Owned by: draft-ietf-httpbis-p2-semantics@…
Priority: normal Milestone: 24
Component: p2-semantics Severity: In WG Last Call
Keywords: Cc:


p2 explains the semantics of 100-continue: "If the origin server responds with a final status code, it must not have performed the request method and may either close the connection or continue to read and discard the rest of the request."

In my (admittedly quick) testing, pretty much nobody does this, at least by default; i.e., if I send a GET to a server with Expect: 100-continue, it's going to give me a 200 or 30x, not a 417. Sure, they might send 417 for a request with a body, but as written pretty much no one is conformant.

One thing we could do would be to only place requirements upon proxies and servers when Expect: 100-continue is on a request with a body.

Stepping back, though, I have to wonder if it's reasonable to only allow 100 (Continue) or, effectively, an error (since the request can't be "applied") in the presence of Expect: 100-continue. I've seen many implementations that purposefully ignore Expect: 100-continue and send back 200 (OK) responses to avoid the interop problems that expect/continue brings.

OTOH if we do maintain the notion that a final response to an Expect: 100-continue request needs to NOT be applied on the server, we should use more specific terminology (i.e., say that it needs to be a 4xx or 5xx response status, not just a "final response.").

Change History (6)

comment:1 Changed 10 years ago by mnot@…

  • Milestone changed from unassigned to 23

Proposed text:

The request includes a payload body and the client will wait for a 100 (Continue) response after sending the request header section but before sending the payload body. The 100-continue expectation does not use any expect-params.


The request includes a payload body and, after sending the request header section, the client will wait before some (possibly unbounded) period of time before sending the payload body, to give the server an opportunity to reject the request with a final status code. The server can shorten the wait time by sending a 100 (Continue) response (or a final status code).

  • And, change:

The primary purpose of the 100 (Continue) status code (Section 6.2.1) is to allow a client that is sending a request message with a payload to determine if the origin server is willing to accept the request (based on the request header fields) before the client sends the payload body. In some cases, it might either be inappropriate or highly inefficient for the client to send the payload body if the server will reject the message without looking at the body.


The 100-continue expectation and 100 (Continue) status code (Section 6.2.1) are useful when a request that has a large body might be rejected by the server; for example, if the request requires authorization (ref to p7). In these situations, clients will often pause between sending the request headers and its body, to give the server an opportunity to refuse the request (by sending a final status code).

In cases where the request is successful, this can cause a needless delay, as the client waits to time out (a typical period is one second). If the client has send the 100-continue expectation, the server can use the 100 (Continue) status code to indicate that the request is not going to be rejected, thereby avoiding the remainder of this delay period.

Note that this mechanism does not change the request message parsing algorithm; in particular, whether or not a final response status code is sent, the client still needs to send a complete request message. As such, if a final status code is received, clients will often choose to close the connection, rather than send a complete request (e.g., if it is length-delimited).

comment:2 Changed 9 years ago by julian.reschke@…

  • Milestone changed from 23 to unassigned

comment:3 Changed 9 years ago by fielding@…

From [2350]:

Rewrite the sections on Expect and 100-continue to simplify the requirements (remove redundant or impossible conditions) and fix contradictions; addresses #458 #466 #467

comment:4 Changed 9 years ago by fielding@…

  • Milestone changed from unassigned to 24
  • Resolution set to incorporated
  • Status changed from new to closed

comment:5 Changed 9 years ago by mnot@…

  • Resolution incorporated deleted
  • Status changed from closed to reopened

comment:6 Changed 9 years ago by mnot@…

  • Resolution set to fixed
  • Status changed from reopened to closed
Note: See TracTickets for help on using tickets.