Prompt and scope
An interviewer may ask: “What do HTTP 1xx interim responses and 102 Processing mean? If a long request needs progress feedback, how would you design it?”
The signal is whether you can separate a protocol signal that the request is not finished, a final response, and an asynchronous operation resource. RFC 9110 allows zero or more 1xx interim responses before the final non-1xx response; it does not turn 102 into a generic percentage-progress protocol. 102 originated as a WebDAV status in RFC 2518 and was removed from WebDAV by RFC 4918. Start by checking protocol versions, clients, and intermediaries before proposing it.
What the interviewer is testing
- Whether you know that 1xx responses are interim and do not complete a request.
- Whether you can distinguish 100 Continue, 101 Switching Protocols, and 102 Processing.
- Whether you recognize 102's WebDAV history instead of promising universal support.
- Whether you can choose 202 plus a status resource, SSE, or WebSocket for a long-running product flow.
- Whether you account for proxies, timeouts, retries, cancellation, idempotency, and result retrieval.
Clarifying questions
- Must the request remain synchronous, or can the work become a background operation?
- Will the reverse proxy and gateway forward and expose 1xx responses?
- Does the product need a keep-alive hint, or observable stages and percentages?
- Does the operation have side effects that a retry could repeat?
- Is there a separate result resource with expiry and access control?
A 30-second answer
You can say:
A 1xx response is interim; the client still needs a final non-1xx response. 102 Processing came from a WebDAV long-operation scenario, so it is not a general progress model and cannot be assumed to traverse every intermediary. If the work can be asynchronous, I would return 202 with an authorized status resource exposing stable states, errors, cancellation, and a result link. If the connection must remain open, I would consider SSE or another explicit event protocol based on client support, then test the real proxy path.
Step-by-step reasoning
Define the response lifecycle
Separate interim and final stages:
HTTP/1.1 102 Processing
HTTP/1.1 200 OK
Content-Type: application/json
{"result":"done"}102 does not finish the request or promise completion. RFC 9110's important constraint is that a final non-1xx response still follows; losing an interim response does not by itself prove a business failure.
Set the boundary for 102
RFC 2518 described 102 as a WebDAV hint during a long operation, helping a client avoid treating an active connection as dead. It is not a workflow resource with standardized percentComplete, stage values, and error semantics. RFC 4918 removed that WebDAV definition, so a new API must document its target implementations and compatibility rather than relying on the number alone.
Choose a protocol for the product need
When polling is acceptable, separate the action from its state: return 202 and a Location for submission, then expose stable states such as Pending, Running, Succeeded, Failed, and Canceled. Add SSE when a live UI needs stage updates; evaluate WebSocket only when bidirectional control is justified. Each option needs a plan for reconnects, backoff, cancellation, and authorization.
Handle duplicate submission and eventual completion
Accept an idempotency key for creation and persist a request fingerprint with the operation ID. A retry with the same key returns the same operation instead of enqueueing another side effect. Make status reads repeatable, protect result URLs with tenant checks and expiry, and expose structured errors with a retry boundary. A disconnect, timeout, or 102 response is not a business conclusion.
Model high-quality answer
I would first distinguish a keep-alive hint from observable progress. If a synchronous request may exceed a gateway timeout, I would not use 102 as a generic progress API: 1xx is interim, 102 has WebDAV history, and intermediary support is uneven. My default is to validate the submission, return 202 with an operation ID and status URL, and expose bounded stage information, update time, structured errors, cancellation, and a result URL. The submission carries an idempotency key so retries do not create duplicate work. For a live UI I can add SSE, with recovery through the last event ID or the status resource. Security or compliance risks still use the formal escalation and audit path. This keeps protocol signals, operation state, and result resources separate.
Common mistakes
- Calling 102 a percentage-progress response without a field or client contract.
- Treating any 1xx as success or as permission to close the connection.
- Ignoring RFC 4918's removal of 102 from WebDAV and claiming universal WebDAV support.
- Discussing only the origin server while skipping CDN, proxy, gateway, and browser tests.
- Returning 202 without a status resource, idempotency strategy, failure state, or result authorization.
- Treating disconnects, timeouts, or retries as proof of failure and duplicating side effects.
Follow-up questions and responses
1. What is the key difference between 102 and 202?
102 is an interim response for the same request; the final response is still pending. 202 is the final response that says the request was accepted for processing, while the result may not be ready. For independently observable and recoverable work, 202 plus a status resource is usually clearer.
2. What if a proxy does not forward 1xx responses?
Treat 1xx as an optional optimization, never as the only correctness signal. Provide recoverable state through a status endpoint, SSE, or a controlled client path, and test the actual intermediary chain.
3. When would you still use 102?
Only when the end-to-end stack explicitly supports it, the requirement is an interim hint for the same long request, and the team accepts the compatibility boundary. Record client, proxy, and timeout evidence, and keep a correct fallback that works without 102.