1xx HTTP Status Codes
1xx status codes are informational responses sent before the final response.
This is an educational guide. The pages linked here are documentation pages served as 200 OK, even when the HTTP status code being explained is an error response.
What 1xx means
Informational responses are interim HTTP responses. They tell the client that the server has received the request and that the exchange is still in progress. A final non-1xx response normally follows.
Where 1xx responses appear
- Large uploads that use Expect: 100-continue before sending the request body.
- Protocol upgrades, such as switching from HTTP to WebSocket.
- Long-running WebDAV operations where the server wants to prevent a client timeout.
- Early resource hints sent before the final response headers.
Implementation notes
- Do not treat a 1xx response as the final result of the request.
- Most application code sees the final response because HTTP clients often handle interim responses internally.
- 1xx responses are useful for transport behavior, not for normal success or failure handling.
Rules for every 1xx response
What RFC 9110 says about every 1xx response, quoted from the RFC.
- MUST NOT (server; response): Do not send any 1xx response to an HTTP/1.0 client. When: The client uses HTTP/1.0. Table row
Since HTTP/1.0 did not define any 1xx status codes, a server MUST NOT send a 1xx response to an HTTP/1.0 client. RFC 9110 §15.2
- No keyword (sender; content): A 1xx response ends at its header section. It has no content and no trailers. Table row
A 1xx response is terminated by the end of the header section; it cannot contain content or trailers. RFC 9110 §15.2
- MUST (client; response handling): Parse one or more 1xx responses before the final response, even when none was expected. Table row
A client MUST be able to parse one or more 1xx responses received prior to a final response, even if the client does not expect one. RFC 9110 §15.2
- MUST (proxy; forwarding): Forward 1xx responses to the client. When: Unless the proxy itself requested the 1xx. Table row
A proxy MUST forward 1xx responses unless the proxy itself requested the generation of the 1xx response. RFC 9110 §15.2
The same rules are in the response obligations table and its JSON.
All 1xx status codes
| Code | Name | Meaning |
|---|---|---|
| 100 | Continue | The server has received the request headers and the client should proceed to send the request body (in the case of a request for which a body needs to be sent; for example, a POST request). Sending a large request body to a server after a request has been rejected for inappropriate headers would be inefficient. To have a server check the request's headers, a client must send Expect: 100-continue as a header in its initial request and receive a 100 Continue status code in response before sending the body. If the client receives an error code such as 403 (Forbidden) or 405 (Method Not Allowed) then it should not send the request's body. The response 417 Expectation Failed indicates that the request should be repeated without the Expect header as it indicates that the server does not support expectations (this is the case, for example, of HTTP/1.0 servers). |
| 101 | Switching Protocols | The requester has asked the server to switch protocols and the server has agreed to do so. |
| 102 | Processing | A WebDAV request may contain many sub-requests involving file operations, requiring a long time to complete the request. This code indicates that the server has received and is processing the request, but no response is available yet. This prevents the client from timing out and assuming the request was lost. |
| 103 | Early Hints | Used to return some response headers before final HTTP message. |