Processing
ActiveHTTP 102 Processing is a WebDAV status code that indicates the server has received and is processing a long-running request, but has not yet completed it. It prevents the client from timing out. 102 is informational – the server will follow with a final 2xx, 3xx, 4xx, or 5xx response. It is rarely used outside of WebDAV.
Description
102 Processing is defined in WebDAV (RFC 2518, superseded by RFC 4918). It was designed for WebDAV operations that may take a long time – like a COPY or MOVE of a large directory tree. The server sends 102 to reassure the client that the request is still being processed and hasn't timed out. In practice, 102 is almost never used in modern REST APIs. HTTP clients that don't understand 102 can ignore it as any unrecognized 1xx code. 103 Early Hints has largely displaced 1xx-series usage for new use cases.
Examples
COPY /files/large-folder HTTP/1.1
Host: webdav.example.com
Destination: /archive/large-folder
# Server sends while processing:
HTTP/1.1 102 Processing
# Then final response:
HTTP/1.1 207 Multi-Status
Content-Type: application/xmlEdge Cases
- •102 is a WebDAV-specific status. It should not be sent by general HTTP servers.
- •HTTP clients must ignore unrecognized 1xx responses per RFC 9110 – a client that doesn't know 102 should simply wait for the next response.
- •Many HTTP/1.1 proxies and libraries do not forward 102 correctly. Test client compatibility before relying on it.
When You'll See This
- →Long-running WebDAV COPY or MOVE operations
- →WebDAV PROPFIND with deep directory traversal
- →Any server operation expected to take more than 30 seconds
Implementation References
| Language | Constant |
|---|---|
| Go | 102 (no standard constant in net/http) |
| Node.js | 102 (not in http.STATUS_CODES by default) |
| Python | http.HTTPStatus(102) |
History
Defined in RFC 2518 (WebDAV, 1999) and carried over to RFC 4918. One of the few 1xx status codes in the 100–199 range alongside 100 Continue, 101 Switching Protocols, and 103 Early Hints.
Related Status Codes
FAQ
Should I use 102 in a REST API for long operations?
No. For long-running operations in REST APIs, use the accepted async pattern: return 202 Accepted immediately with a polling URL in the Location header or body. The client polls for completion. 102 is WebDAV-specific and not appropriate for general REST APIs.