102 vs 202: Processing vs Accepted
Both tell the client “not done yet,” but 102 is a deprecated WebDAV keepalive while 202 is the modern standard for asynchronous operations.
| Aspect | HTTP 102 — Processing | HTTP 202 — Accepted |
|---|---|---|
| RFC | RFC 4918 (WebDAV, deprecated) | RFC 9110, Section 15.3.3 |
| Status class | 1xx Informational | 2xx Success |
| Meaning | Operation in progress — connection keepalive | Request accepted; processing will happen asynchronously |
| Has response body | No | Yes — typically includes job ID and status URL |
| Connection behavior | Keeps the current HTTP/1.1 connection open | Closes the response; client polls or waits for callback |
| Current status | Deprecated | Active — widely used |
| Cacheable | No | No |
| HTTP/2 compatible | No | Yes |
102: The Deprecated WebDAV Heartbeat
102 Processing was a mechanism for HTTP/1.1 WebDAV servers to prevent client timeouts during operations that took longer than a few seconds. Because HTTP/1.1 connections can only carry one request/response at a time, a long-running operation blocks the connection. Sending periodic 102 responses kept the connection alive.
The approach had significant problems. It did not work with CDN and proxy infrastructure. HTTP chunked transfer encoding provided a better streaming mechanism. And with HTTP/2 — which multiplexes multiple streams over a single connection — the entire problem 102 solved stopped being a problem. RFC 4918 was subsequently updated to remove 102.
202: The Modern Async Pattern
202 Accepted is the current standard for any operation that cannot complete synchronously within a reasonable HTTP response time. The server accepts the request, queues it for processing, and immediately returns a response with a job identifier and a URL for status polling.
POST /api/exports HTTP/1.1
Content-Type: application/json
{"format": "csv", "range": "2024"}
HTTP/1.1 202 Accepted
Location: /api/exports/job_8f2a
Content-Type: application/json
{
"jobId": "job_8f2a",
"status": "queued",
"statusUrl": "/api/exports/job_8f2a",
"estimatedSeconds": 45
}The client then polls the statusUrl or waits for a webhook callback. This pattern works correctly with HTTP/2, CDNs, load balancers, and all modern infrastructure. The 202 response closes the HTTP connection immediately; there is no connection-state coupling between the request and the eventual completion.
Which to Use
Never use 102 in new applications. Use 202 for any operation that requires asynchronous processing: video transcoding, batch data exports, email sending, report generation, or any job that takes more than a few hundred milliseconds. Pair 202 with a status endpoint, webhook callback, or Server-Sent Events stream for the final result.
If you encounter 102 in an existing WebDAV client or server, treat it as a no-op keepalive and wait for the final response. Do not build new logic around 102 reception.
FAQ
Does 202 guarantee the operation will eventually succeed?
No. RFC 9110 explicitly states that 202 is “intentionally non-committal.” The operation may still fail. The status endpoint or webhook must communicate the final success or failure outcome.
Should 202 always include a Location header?
Yes, if the client needs to track the operation. The Location header should point to the status resource. Omitting it creates a fire-and-forget situation where the client has no way to determine what happened.
Can I use 102 for non-WebDAV long polling?
No. 102 is deprecated, not supported by HTTP/2, and incompatible with most modern infrastructure. Use Server-Sent Events or WebSockets for streaming updates, and 202 for async job acknowledgment.
Full Guides
HTTP 102 Processing — full guide · HTTP 202 Accepted — full guide · All comparisons