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
- 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.
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.
How to fix it
As the client
- Ignore the interim response and keep reading until the final status arrives.
- Raise the client read timeout for WebDAV operations on large collections.
As the server
- 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
PROPFIND /dav/projects/ HTTP/1.1 Host: files.example.com Depth: infinity HTTP/1.1 102 Processing HTTP/1.1 207 Multi-Status Content-Type: application/xml; charset=utf-8