A WebDAV request from client to server may contain multiple sub-requests that necessitate a long time frame to complete. The HTTP Status Code 102 indicates that the server has received and is processing the request, but that it does not have a final response yet.
This explicit status prevents the client from assuming that the request has timed out and thus that the request has been lost.
Frequently Asked Questions
What does HTTP status code 102 mean?
HTTP 102 Processing is an informational response that tells the client the server has received the full request and is actively working on it, but does not yet have a final response. It belongs to the 1xx class of HTTP status codes, which are all interim and informational in nature. The code was introduced in the WebDAV specification to handle complex, long-running operations.
When does a server return a 102 status code?
A server returns 102 when a request is expected to take a significant amount of time to complete — for example, a WebDAV request that contains multiple sub-requests. Sending 102 reassures the client that the request is being processed rather than lost, preventing the client from assuming a timeout has occurred and abandoning the request prematurely.
Is HTTP 102 still in use today?
HTTP 102 was defined in RFC 2518 but was removed from the revised WebDAV specification in RFC 4918. It is no longer part of current HTTP specifications, though it remains registered in the IANA HTTP Status Code Registry. Most modern servers and frameworks do not implement it, and you are unlikely to encounter it outside of legacy WebDAV environments.
What is the difference between HTTP 102 and HTTP 100?
HTTP 100 Continue is sent before the full request body is received, allowing the server to check request headers first — typically used when the client sends an Expect: 100-continue header. HTTP 102 Processing, by contrast, is sent only after the full request has been received, to signal that the server is still computing the response. Both are interim 1xx codes, but they serve different phases of the request cycle.
How should a client handle an HTTP 102 response?
A client that receives a 102 response should continue waiting for the final response rather than treating the connection as timed out or failed. Clients that do not explicitly support 102 will simply ignore it, which is safe — the HTTP specification requires compliant clients to ignore unrecognized 1xx responses. No special error handling or retry logic is needed on the client side.
Do I need to "fix" an HTTP 102 response I see in my logs?
A 102 response is not an error and does not require a fix. It is an informational signal that the server is still processing a long-running request. If you see it unexpectedly, check whether your server or a middleware layer is implementing WebDAV or a custom interim-response mechanism. Because 102 is deprecated from current specs, seeing it in a modern non-WebDAV context may indicate a misconfigured or legacy component worth investigating.
