100 vs 102: Continue vs Processing

How 100 Continue Works

100 Continue solves a bandwidth problem: when a client wants to send a large request body, it can first check whether the server will accept it before transmitting the data. The client sends headers with Expect: 100-continue and waits. If the server responds 100, the client sends the body. If the server responds 417 Expectation Failed (or any other error), the client knows not to transmit the body and has saved bandwidth.

A typical scenario is uploading a large file to an endpoint that requires authentication. The client sends the request headers including Authorization and Expect: 100-continue. The server validates the auth token and, if valid, sends 100. The client then sends the 500 MB upload body. Without this mechanism, an authentication failure would only be discovered after all 500 MB had been transmitted.

PUT /uploads/video.mp4 HTTP/1.1
Host: api.example.com
Authorization: Bearer token123
Content-Length: 524288000
Expect: 100-continue

HTTP/1.1 100 Continue

[client now sends 500MB body]

HTTP/1.1 201 Created

Most HTTP clients implement this automatically. curl sends Expect: 100-continue for requests over 1024 bytes. Python’s requests library and Java’s Apache HttpClient do the same. The 100 response arrives as an intermediate response before the final 2xx/4xx/5xx.

How 102 Processing Works (and Why It’s Deprecated)

102 Processing was defined in RFC 4918 as a WebDAV mechanism to keep HTTP/1.1 connections alive during long-running server operations. WebDAV operations like copying large directory trees could take minutes. Without 102, the HTTP/1.1 connection would time out on the client side before the operation completed.

The server would send 102 responses periodically — essentially heartbeats — to signal that processing was still in progress. The client would receive these and reset its timeout timer:

COPY /files/large-collection/ HTTP/1.1
Destination: /backup/large-collection/

HTTP/1.1 102 Processing
[... 30 seconds later ...]
HTTP/1.1 102 Processing
[... 30 seconds later ...]
HTTP/1.1 207 Multi-Status
[operation complete]

102 was removed from current specifications for two reasons. First, it was incompatible with HTTP chunked transfer encoding, which provides a better mechanism for streaming responses. Second, it did not work with CDN and proxy infrastructure that needed to buffer complete responses. HTTP/2 and HTTP/3 eliminated the need for 102 entirely through multiplexing, which allows multiple streams on one connection and eliminates per-connection timeouts.

Decision Rule: When to Use Each

Use 100 Continue on the server side when you want to validate request headers (authentication, content-type, size limits) before the client sends a large body. Most servers that support this do so automatically — nginx has proxy_expect_100_continue, Node.js has the checkContinue event. You should never need to send 102 Processing in a new application. If you have a long-running operation, use 202 Accepted with a job ID, or stream the response using chunked transfer encoding or Server-Sent Events.

FAQ

Can I return 100 without receiving an Expect header?

Technically no. RFC 9110 specifies that 100 is sent specifically in response to a request with Expect: 100-continue. Sending it spontaneously is not standard behavior and may confuse clients.

Is 102 completely gone from HTTP?

102 is still in the IANA status code registry and still appears in some WebDAV server implementations. It is just no longer part of the active WebDAV specification. New applications should not use it.

What replaced 102 for long-running operations?

202 Accepted (with status polling or webhooks), Server-Sent Events, and WebSockets. These patterns work correctly with HTTP/2, CDNs, and modern proxy infrastructure.

Full Guides

HTTP 100 Continue — full guide · HTTP 102 Processing — full guide · All comparisons

Related comparisons

• 100 vs 103
• 102 vs 202