102 Processing 1xx
The server has accepted the complete request but processing will take time, and this response prevents the client from timing out.
What does 102 mean?
A 102 Processing response is an interim signal meaning "I've received your full request and I'm working on it — this is just a heartbeat so you don't think the connection has died while you wait." It originated in WebDAV (RFC 2518), designed for operations that might take a long time to complete (like a large file copy or move involving many sub-resources), where a client might otherwise time out waiting for a final response with no indication that anything was happening.
102 has become largely obsolete in modern HTTP — the official specification (RFC 9110) explicitly deprecates it, noting that most clients don't do anything useful with 1xx responses beyond 100, and recommending alternative patterns (like 202 Accepted with a status-polling endpoint) for long-running operations instead.
How a 102 behaves
- It's an interim/informational response (1xx) — a final status code follows once processing actually completes
- It carries no meaningful body
- Multiple 102 responses could theoretically be sent as periodic "still working" signals during a long operation
- It's explicitly deprecated in modern HTTP specifications — while technically still a registered status code, current guidance steers away from relying on it
Why it's rarely used today
The core problem 102 tried to solve — "how do I keep a client informed during a long-running operation without it timing out" — is now more commonly addressed through different patterns:
- Asynchronous operations with 202 Accepted: the server immediately responds with 202 and a way to check status later (a job ID, a status URL), rather than holding the connection open at all
- WebSocket/Server-Sent Events: for operations where ongoing progress updates are genuinely useful to communicate, a persistent connection with structured progress messages is more flexible than periodic 1xx responses
- Client-side timeout configuration: clients can simply be configured with longer timeouts for endpoints known to take a while, sidestepping the need for server-side "keep-alive" signals entirely
Common scenarios (historical/WebDAV context)
If you're building the API or website:
- You're unlikely to need 102 in a modern API design — if you have long-running operations, the 202-plus-polling (or async job) pattern is the current recommended approach
- If working with legacy WebDAV implementations, 102 might still appear as part of that ecosystem's conventions
If you're calling an API:
- Modern HTTP clients generally don't expect or specifically handle 102 — if you encounter it, it likely indicates interaction with an older or WebDAV-based system
If you're a website visitor:
- Not applicable — entirely a connection-level, legacy detail
102 vs 202
| 102 Processing | 202 Accepted | |
|---|---|---|
| Type of response | Interim (1xx) — connection stays open, final response still pending | Final (2xx) — the request has been accepted, but processing happens separately |
| Client experience | Keeps a single long-held connection alive | Connection closes quickly; client checks status separately (polling, webhook, etc.) |
| Modern recommendation | Deprecated/discouraged | Preferred pattern for long-running operations |
Real-world examples
102 is primarily of historical interest at this point — WebDAV implementations from the era when this code was introduced may have used it for operations like recursive directory copies/moves, but contemporary API design for long-running operations almost universally favors the 202-plus-status-polling pattern, which doesn't require holding a connection open at all.
SEO implications
None — 102 is an interim response with no relevance to indexable content.
FAQ
Is 102 still used today?
Rarely — it's part of the official status code registry but explicitly deprecated in current HTTP specifications, with most clients not implementing any special handling for it. Modern long-running-operation patterns favor 202 with status polling instead.
What's the modern alternative to 102?
Return 202 Accepted immediately, along with information the client can use to check on progress later (a job ID, a status-check URL, or a webhook that fires on completion) — rather than holding a connection open with periodic "still working" signals.
Why was 102 deprecated?
Because most HTTP clients never implemented meaningful handling for 1xx responses beyond 100, making 102 largely ineffective in practice — clients either ignored it or didn't change their timeout behavior based on it, undermining its intended purpose.
Will I encounter 102 in modern API development?
Very unlikely — if you're designing or consuming APIs today, you're far more likely to encounter the 202-plus-polling pattern for long-running operations than anything using 102.
Is 102 related to WebDAV like 422-424?
Yes — like 422, 423, and 424, 102 has WebDAV origins, part of that protocol's relatively ambitious feature set for handling complex, potentially long-running operations over HTTP.
Fun fact
102 might be the clearest example in this entire reference of a status code that was a reasonable idea for its time but has been effectively superseded by better architectural patterns — rather than being removed from the registry entirely (which would be disruptive to any systems still referencing it), it remains technically defined but explicitly discouraged, a kind of "deprecated but not deleted" status that mirrors how many software APIs handle their own obsolete features.