HTTP 100 Continue – Free, Online, Private

What HTTP 100 means

100 is an interim response. The server has read the request headers, they are acceptable, and the client should proceed with the body. The final status comes later and is a normal 2xx, 4xx, or 5xx. Clients send Expect: 100-continue when the body is large or expensive to generate and they want a chance to stop if the headers would be rejected.

100 Continue belongs to the 1xx informational class. Clients that only look at the class will group it with its neighbors. Clients that care about the exact code should use the narrower rule on this page, because the class is only the first digit.

When you see HTTP 100

When you see HTTP 100 Continue, stop on that exact status line. 100 Continue tells the client to send the request body it has been holding. The trace that usually produces it: The client set Expect: 100-continue and the server accepted the headers. The 1xx informational class only tells you the first digit. A neighbor in that class is a different fault, and the fix on this page does not transfer to it.

Use 100 only as that interim reply to Expect: 100-continue. Do not use it as the final status of a request, and do not send a body with it. A server that does not want the body should skip 100 and send the final error, typically 401, 413, or 415.

How to fix HTTP 100

To fix HTTP 100, change the condition that made the server choose Continue. Send the body after 100, or send it anyway after a short timeout if the server ignores Expect. Do not show 100 to a user as the outcome. There is nothing to retry. The request is still in progress. Retry policy applies to the final status. If the log line is a different code, leave this page. The mix-up people make with 100 is this one: The common mix-up is with 102 Processing, which is also interim but means the server is still working, and with 417 Expectation Failed, which is the refusal of the Expect header.

• A proxy forwarded the expectation and the origin answered before the body was uploaded.
• A test client printed the interim status and treated it as the result of the call.
• A server sent 100 even though the client did not send Expect, which strict clients are allowed to ignore.

An access log that only stores 100 is not enough to tell these apart. Keep the method, the path, and a request id. Do not keep the Authorization header or a request body that might be a token. The status explains the outcome. It is not a place to echo secrets back to the client either.

Example response

HTTP 100 ContinueHTTP/1.1 100 Continue

There are no headers required beyond the status line, and there is no body. After this, the client writes the body and the server later sends, for example, 201 Created. If you log only the first status line, you will record a success that has not happened yet.

What the client should do

Send the body after 100, or send it anyway after a short timeout if the server ignores Expect. Do not show 100 to a user as the outcome.

100 is not a representation of the resource and must not be cached. Caches forward it or drop it. A stored 100 would be nonsense.

There is nothing to retry. The request is still in progress. Retry policy applies to the final status.

Codes people confuse with HTTP 100

The common mix-up is with 102 Processing, which is also interim but means the server is still working, and with 417 Expectation Failed, which is the refusal of the Expect header.