102 Processing: Keeping Connections Alive During Long Operations
Why 102 Processing Exists
HTTP clients have built‑in timeouts. If a request takes more than a few seconds without any response, the client may close the connection and display an error. By sending 102 Processing periodically (or once at the beginning of a long operation), the server tells the client: "I'm still here, keep waiting."
How to Use 102 in Practice
The server should send the 102 response before the client's timeout period expires, and then continue processing. Once the operation finishes, the server sends the final HTTP status (e.g., 200 OK or 500 Internal Server Error).
| Step | Direction | HTTP Message |
|---|---|---|
| 1 | Client → Server | POST /generate-report HTTP/1.1 |
| 2 | Server → Client | HTTP/1.1 102 Processing |
| 3 | Server → Client | HTTP/1.1 200 OK |
Important Considerations
- Not a final response — the client must continue to wait for the final status.
- Can be sent multiple times — for extremely long operations, you may send several 102 responses to keep the connection alive.
- Not widely supported — not all HTTP clients handle 102 correctly. Check your client library's behavior before relying on it.
- Alternatives — many modern APIs use 202 Accepted with a status URL and polling, or WebSocket for real‑time updates.
Frequently Asked Questions
Is 102 Processing the same as 100 Continue?
No. 100 Continue is about the handshake before sending the request body. 102 Processing is sent after the request body has been received and the server is working on it.
Does every server support 102?
Not by default. It's rarely used in modern web development because of better alternatives. However, some older systems and WebDAV servers still use it.
What happens if the client times out despite 102?
If the client's timeout is shorter than the server's processing time, the client may still abort the request. To prevent this, you can increase the client timeout or use a different approach (e.g., background jobs with polling).