HTTP 102 Processing – Free, Online, Private

What HTTP 102 means

102 tells the client that the request was received and is being processed, so the client should not time out. It comes from WebDAV, RFC 2518, not from ordinary page loads. The final status arrives later. Like 100, it is not the result of the operation. A lock, a copy, or a search that takes a long time is the case WebDAV had in mind.

102 Processing 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 102

When you see HTTP 102 Processing, stop on that exact status line. 102 Processing is a WebDAV interim status meaning the server is still working on a slow request. The trace that usually produces it: A PROPFIND or a large COPY is taking longer than a proxy's idle timeout. 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.

Send 102 only if you are a WebDAV server, or a client you control understands it, and the operation is still running. Do not send it as a heartbeat on a normal JSON API. Clients that do not know 102 may treat it as an unknown status and fail the call before your real 207 or 200 arrives.

How to fix HTTP 102

To fix HTTP 102, change the condition that made the server choose Processing. If you understand 102, keep waiting. If you do not, you may ignore a 1xx and keep reading, which is also fine. Do not retry just because you saw 102. Do not retry while the original request is still open. A second COPY or lock can make the conflict you were trying to avoid. If the log line is a different code, leave this page. The mix-up people make with 102 is this one: 100 Continue is about sending a body. 102 is about a request the server already has and has not finished. 202 Accepted means the work was queued and this HTTP request is over.

• A server emitted 102 on a timer and never sent a final status, so the client waited until its own timeout.
• A library logged 102 as an error because it only treats 2xx as success and does not know interim 1xx.
• A proxy buffered the interim response and the timeout the 102 was meant to prevent still fired.

An access log that only stores 102 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 102 ProcessingHTTP/1.1 102 Processing

The status line is the whole message. No body. The client resets its timeout and keeps reading. The next status is the real one, often 207 Multi-Status for WebDAV. If nothing else arrives, the operation did not finish.

What the client should do

If you understand 102, keep waiting. If you do not, you may ignore a 1xx and keep reading, which is also fine. Do not retry just because you saw 102.

Do not cache 102. It is progress for one in-flight request.

Do not retry while the original request is still open. A second COPY or lock can make the conflict you were trying to avoid.

Codes people confuse with HTTP 102

100 Continue is about sending a body. 102 is about a request the server already has and has not finished. 202 Accepted means the work was queued and this HTTP request is over.