Back to list
100

Continue

1xx Informational

.md

ELI5

Imagine calling ahead before mailing a very heavy package: 'Can you accept this?' The post office says yes, so you drive it over. That's 100 Continue — the server greenlit the request headers, so send the rest of the data.

Server perspective

Use 100 as an interim response when a client asked whether it should continue sending the request body.

When to use

  • •Send 100 when the request uses Expect: 100-continue and the server is willing to receive the body
  • •Use it when method, target URI, and headers are acceptable, but you want to avoid receiving a large body only to reject it later
  • •Large uploads where the client sends Expect: 100-continue
  • •Requests where auth, size limits, or permissions can be validated from headers alone — before committing to sending the body
  • •Avoiding unnecessary bandwidth when a request might be rejected early

How to respond

  • •Validate the request line and headers first, then either send 100 or an immediate final response if the outcome can already be determined from headers alone
  • •When you decide to honor Expect: 100-continue, send 100 immediately; the origin server MUST NOT wait for the content before sending 100
  • •You may omit 100 if some or all of the request body already arrived, but if you send 100 you must still send a final response after processing completes

Headers to consider

  • •Look for Expect: 100-continue on the request; no status-specific response header is required for the 100 itself.

Response body

  • •Do not include a response body in a 100 response.

Server-side pitfalls

  • •Do not send 100 as the final outcome of the request
  • •Do not send 100 when you already know the request should fail from headers alone; send the final 4xx or 5xx response instead
  • •Do not send 100 and then leave the client waiting; a final response must still follow unless the connection closes prematurely
  • •Small request bodies where the extra round trip is not worth it
  • •When the server cannot validate headers before reading the body
  • •Normal GET or HEAD requests without meaningful bodies
  • •As a substitute for a final response — 100 must always be followed by a real status code like 200 or 400

Examples

Large file upload with validation

Request:POST https://api.example.test/api/upload # Headers Expect: 100-continue Content-Length: 52428800 Content-Type: video/mp4 # Body <50 MB video file>
Response:201 Created # Headers Location: https://api.example.test/api/uploads/123 Content-Type: application/json # Body { "id": "upload_123", "status": "stored" }

Internally, the server sent 100 Continue after inspecting the headers; the client held the body until that approval arrived.

Upload rejected before body transfer

Request:POST https://api.example.test/api/upload # Headers Expect: 100-continue Content-Type: video/x-msvideo Content-Length: 52428800 # Body <50 MB video file>
Response:415 Unsupported Media Type

The server rejected from headers alone — the body was never transmitted, saving 50 MB of bandwidth.

References

Related Status Codes

101

Switching Protocols

The server is saying, 'Let's keep talking, but switch to a different protocol for the rest of this connection.'

102

Processing

The server is saying, 'I’m still working on this. Don’t assume the request was lost just because it’s taking a while.'

WebDAV
103

Early Hints

The server is giving the browser a head start: 'You’ll probably need these files, so start getting them while I finish the real response.'