102 Processing
WebDAV interim response telling the client that a long-running request is still being worked on so it does not time out.
Status
HTTP/1.1 102 Processing
Details
- Category: 1xx
- Status: Deprecated. Registered, but the defining specification marks it obsolete.
- Specification: RFC 2518 §10.1, RFC 4918: Removed 102 from WebDAV
- Cacheable: Not cacheable
- Response body: Must not be sent
- Retry: Not applicable
102 was defined for WebDAV methods that can take a long time, such as a PROPFIND across a deep collection or a COPY of a large tree. The server sends 102 to keep the client from concluding that the connection is dead, then sends the real status when the operation finishes.
It is effectively dead. RFC 4918, which replaced RFC 2518, dropped the code and noted that it saw almost no deployment. The number is still in the IANA registry, but new services should hold the connection with normal TCP keepalives, or move the work to a job that returns 202 Accepted with a status URL.
Note: RFC 4918 removed 102 from WebDAV after almost no deployment. For genuinely long work, return 202 Accepted with a status URL instead.
Common causes
- A WebDAV server implementing RFC 2518 is working through a long request.
- Legacy document management or content repository software written against the original WebDAV spec.
Usage notes
For clients
- Ignore the interim response and keep reading until the final status arrives.
- Raise the client read timeout for WebDAV operations on large collections.
For servers
- Prefer 202 Accepted plus a polling endpoint for anything genuinely long running.
- Do not send 102 to clients that did not negotiate WebDAV. Many HTTP libraries mishandle unexpected interim responses.
Examples
A long-running WebDAV request
HTTP request
PROPFIND /dav/projects/ HTTP/1.1 Host: files.example.com Depth: infinity
HTTP response
HTTP/1.1 102 Processing
HTTP response
HTTP/1.1 207 Multi-Status Content-Type: application/xml; charset=utf-8
Specifications
- RFC 2518 §10.1
- RFC 4918: Removed 102 from WebDAV