Summary

  • Expect: 100-continue lets a client expose its intention to pause before sending request content, giving the server a chance to reject from the method, target and headers.
  • A 100 response only encourages transmission. The origin still owes a final status after processing the body, and an intermediary can sometimes generate the interim response without proving origin acceptance.
  • The client may stop waiting and send anyway. That escape prevents deadlock through older or silent intermediaries, so the mechanism is an optimization rather than a transaction protocol.

The expensive part came after the decidable part

HTTP sends a request line and header section before optional content. That order creates an opportunity. A server may already know from the method, target URI, authorization fields or content metadata that the request will fail, while the client still holds a large body.

Sending everything immediately wastes capacity when the early verdict is 401, 405 or another final rejection. Waiting without a shared signal creates the opposite risk: the client waits for permission while the server waits for the body. 100 Continue was designed inside that gap.

RFC 2068, the first HTTP/1.1 standards-track specification in 1997, defined the informational status and extensive version-sensitive behavior. It recognized that an HTTP/1.1 server could either invite the body or reject before it arrived. Compatibility with HTTP/1.0 made the exchange awkward because an older hop could not be trusted to carry the provisional response.

The expectation made waiting visible

RFC 2616 added the Expect field and its 100-continue expectation. The client no longer relied only on protocol version and timing. A client intending to wait announced that choice in the request headers.

The distinction matters because many clients send headers and content without pausing. A server that receives some or all of the body need not send a now-useless 100. Conversely, a client must not advertise the expectation on a request with no content. The signal describes a concrete pending expenditure.

Under the later consolidated rule, an origin receiving a qualifying HTTP/1.1 request must act from the complete header section. If those fields already justify a final status, it can send that status immediately. Otherwise it sends 100 promptly and must not wait for the body before doing so.

This timing rule prevents the provisional exchange from causing the deadlock it was meant to avoid. The origin either gives a header-based verdict or releases the sender to continue.

Continue did not mean accept

A 1xx response is informational. It has no response content and does not complete the request. If a server sends 100, it must later produce a final status after receiving and processing the content, unless the connection ends prematurely.

The boundary is narrower than familiar words such as approval or preparation suggest. The server has not promised to authenticate the principal, accept the representation, store bytes durably, perform the method or return success. It has said that the information seen so far is not sufficient reason to stop the content.

That is why this is not a two-phase commit. The body can still fail validation; storage can fail; application state can change; authorization may depend on content. Interim permission controls transmission, not the final semantics of the operation.

A proxy could encourage work it could not accept

HTTP intermediaries complicate the source of permission. A proxy receiving the expectation can send a final response it can determine or forward the request line and headers toward the origin. If it knows the next hop is older, it may itself generate 100 to keep the client moving.

Such a response proves only that the immediate chain is willing to continue carrying content. It does not show that the origin has seen the request, much less accepted it. Operational logs that record “100 received” without identifying which hop sent it erase the control boundary.

A 417 Expectation Failed response reveals a different fact: the expectation could not be satisfied along the chain. Specifications advise retrying without it. That advice removes the optional optimization; it does not make every retry harmless. A state-changing method still requires evidence about what reached the origin and whether repetition is safe.

Progress could not depend on hearing permission

RFC 7231 and RFC 9110 preserve an essential asymmetry: a client is not required to wait for a specified duration and may begin sending content without receiving 100. It should not wait indefinitely.

An old intermediary may swallow 1xx. A server may already be receiving the body. A silent path cannot be allowed to hold both parties forever. Client-controlled timeout therefore trades some possible wasted bytes for guaranteed progress.

This also prevents the server from acquiring an indefinite veto through silence. The client asks for an early opinion, but retains authority over when waiting has cost enough. The optimization works best when bodies are large or early rejection likely; the standards deliberately do not name one universal threshold.

Early final responses leave framing work

A final response can arrive while the client is still sending. The connection then contains two problems: the application verdict and the remaining request bytes. The server might close, or it might continue reading and discarding content so later messages remain framed correctly.

Connection reuse makes this more than cleanup. If sender and receiver disagree about whether the body remains on the stream, leftover bytes can be mistaken for another message. Permission, final result and connection disposition must therefore be observed separately.

Sources and limits

The closed set is RFC 2068, RFC 2616, RFC 7231 and RFC 9110. It establishes protocol evolution and semantics, not current adoption, timeout defaults, intermediary compliance, saved bandwidth or performance.