HTTP 102 Processing

Quick reference

Why 102 was created

WebDAV operations can take significant time. A recursive COPY of a large directory tree, a MOVE across storage boundaries, a LOCK traversal over thousands of nested resources, a PROPFIND with a deep depth parameter — these can take seconds or even minutes. HTTP clients have timeouts, typically in the range of 30–120 seconds. If a server takes 90 seconds to process a COPY and sends no response until it completes, most clients will close the connection and report a timeout error before the response arrives.

RFC 2518 introduced 102 as a solution: the server sends one or more 102 responses during processing to keep the connection alive and signal that work is in progress. Each 102 response resets the client’s timeout clock. When processing completes, the server sends the actual final response (typically 207 Multi-Status for WebDAV operations).

COPY /files/large-collection/ HTTP/1.1
Destination: /archive/large-collection/

HTTP/1.1 102 Processing
HTTP/1.1 102 Processing
HTTP/1.1 102 Processing
HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset=utf-8

<?xml version="1.0"?>
<multistatus xmlns="DAV:">
  <response>
    <href>/archive/large-collection/</href>
    <status>HTTP/1.1 201 Created</status>
  </response>
</multistatus>

Why RFC 4918 removed 102

RFC 4918, which obsoleted RFC 2518 as the WebDAV specification, removed 102 for several reasons:

HTTP/1.1 chunked transfer encoding: HTTP/1.1 provides chunked transfer encoding, which allows the server to start sending a response before the full content is ready. For long-running operations, the server can begin streaming the response body as results become available, rather than buffering everything. This provides a more natural keepalive mechanism without needing a special status code.

Limited client support: Most HTTP client libraries do not handle 1xx interim responses well. Clients that use a simple “wait for 200” pattern will ignore or mishandle 102 responses. This limited the practical utility of 102 to dedicated WebDAV clients.

Better alternatives: For truly long-running operations, the recommended pattern is asynchronous job submission: the server immediately returns 202 Accepted with a job ID, and the client polls a status endpoint until the job completes. This is more robust than keeping a connection open for minutes and works across all HTTP clients including those with aggressive timeouts.

Modern alternatives to 102

202 Accepted with job polling: The standard pattern for long-running operations in modern REST APIs. The server accepts the request and immediately returns 202 with a job ID or status URL. The client polls the status URL to track progress.

POST /api/exports HTTP/1.1
Content-Type: application/json

{"report": "annual_sales", "format": "xlsx"}

HTTP/1.1 202 Accepted
Location: /api/jobs/abc123
Retry-After: 10

{"job_id": "abc123", "status": "processing",
 "status_url": "/api/jobs/abc123"}

Server-Sent Events (SSE): For operations where the client needs live progress updates (file processing, batch operations), SSE provides a stream of progress events over a single HTTP connection. The server sends events as processing milestones are hit, and the client displays them in real time.

WebSockets: For bidirectional real-time communication during long operations, WebSockets provide a persistent connection where the server can push progress messages and the client can send control commands (cancel, pause) without polling.

HTTP/2 server push: HTTP/2 server push can be used to proactively send status updates, though it is less commonly used for progress tracking than SSE.

Current state of 102 in the wild

102 is occasionally seen in WebDAV server implementations that predate RFC 4918 or that continue to use it despite its removal from the spec. Some enterprise content management systems (SharePoint, certain DAV-based file servers) may still emit 102 during long operations. In modern non-WebDAV contexts, 102 is rare — the 202-and-poll pattern is overwhelmingly preferred.

If you encounter 102 responses in an HTTP client: ignore them and continue waiting for the final response. Per HTTP specification, all 1xx responses are informational and clients must ignore any 1xx response they do not understand, without closing the connection.

If you are building a server: do not use 102 for new implementations. Use 202 with a status endpoint for long operations, or use SSE for streaming progress.

102 vs 100 vs 202 vs 103

Frequently asked questions

What does HTTP 102 mean?

The server is still processing a long-running request and sending this interim response to prevent the client from timing out. Defined for WebDAV in RFC 2518, removed from the WebDAV spec in RFC 4918. Modern servers should use 202 Accepted instead.

Why was 102 removed from the WebDAV spec?

RFC 4918 removed 102 because better alternatives exist: HTTP/1.1 chunked transfer encoding for streaming responses, and the 202 Accepted + polling pattern for asynchronous operations. Most HTTP clients also handle 1xx responses poorly, limiting the practical utility of 102.

How should a client handle 102?

Ignore it and continue waiting for the final response. Per HTTP specification, clients must be able to handle 1xx informational responses by discarding them and waiting for the next response. Do not close the connection when receiving 102.

Can I use 102 in a non-WebDAV API?

Technically possible, but not recommended. Client support for 1xx handling is inconsistent. Use 202 Accepted with a status polling endpoint instead — it works reliably with all HTTP clients and provides a better user experience for tracking long-running operations.

Related guides

HTTP 100 Continue · HTTP 202 Accepted · HTTP 103 Early Hints

Standards reference

Definitions from the IANA HTTP Status Code Registry and RFC 2518 §10.1. Human-readable guidance by ErrorLookup. · HTTP 102 quick reference →