102 Processing is an interim response from the original WebDAV specification, RFC 2518. A server could send it to tell the client that it had received the complete request and was still working on it, so that the client would not time out during a slow operation such as a recursive COPY or MOVE with Depth: infinity.
RFC 4918, which replaced RFC 2518 in 2007, removed 102 because it was rarely implemented. The code is still registered and some servers still send it, but new applications should not rely on it. For long-running work, return 202 Accepted with a URL the client can poll, or stream progress.
Clients that do not understand 102 may ignore it, as they may ignore any unexpected 1xx response, and keep waiting for the final status.
Example response
HTTP/1.1 102 Processing
HTTP/1.1 207 Multi-Status
Date: Fri, 06 Nov 2026 10:15:32 GMT
Content-Type: application/xml; charset=utf-8
Transfer-Encoding: chunkedSEO and redirect checking
Search engines never see 102 as a page status; only the final response counts. A redirect checker also reports the final status (for WebDAV often 207 Multi-Status), because interim responses are consumed by the HTTP client.
Common causes and use cases
- A WebDAV server reports that a slow recursive
COPY,MOVEorDELETEis still running. - An application sends 102 as a keep-alive signal during long requests. Prefer 202 Accepted with polling.
- Proxies or clients time out on long operations even though the server sent 102. Raise their read timeout or make the operation asynchronous.