Summary

  • 202 Accepted says that a request was accepted for processing while that processing remains incomplete.
  • The operation can still be rejected, cancelled, expire, lose authorization or finish without the intended side effect.
  • Decisions that depend on completion need an asynchronous-operation receipt joining the original request to an authoritative status monitor and terminal result.

Imagine a change controller submitting a request to rotate an access policy. The service returns 202 Accepted with an operation link, so the controller marks the change complete, revokes the old credential and deletes the input material. Minutes later, the queued operation reaches a worker, rechecks policy and is rejected. The request was accepted. The change was never executed.

The error is not in the status code. It is in promoting one stage of a distributed operation into proof of every later stage.

RFC 9110 defines 202 Accepted narrowly. The server has accepted the request for processing, but processing has not completed. The request might eventually be acted upon or might be disallowed when processing takes place. The response is deliberately noncommittal.

That boundary matters because the HTTP response exchange has already ended. RFC 9110 notes that HTTP has no mechanism for sending a later status code from the asynchronous operation back through the completed exchange. A client that treats the initial 202 as a terminal success silently invents a continuation that the protocol did not deliver.

The response representation ought to describe current status and point to, or embed, a status monitor. That is useful guidance, but a URL alone is not a completion receipt. The monitor has to be authoritative for the same operation, accessible under the intended security context, retained long enough for the decision, and explicit about terminal states. A generic queue page, a mutable “latest job” endpoint or a link that later returns 404 cannot safely carry the full claim.

RFC 7240 adds a related but separate signal. A client can send Prefer: respond-async to express a preference for asynchronous handling, and a server can honor that preference with a 202 response. The preference selects an interaction pattern; it does not prove that the deferred work ran. The specification leaves the process for determining the eventual result implementation-specific.

Preference-Applied has an equally narrow role. Under RFC 7240, it can say which request preferences the server honored. It can therefore confirm that asynchronous handling was selected. It cannot confirm a worker start, a write, a notification, a deployment or any other eventual side effect.

An operational record has to preserve at least three different facts. First is acceptance: which request bytes, principal, target, idempotency key and response were observed, and where. Second is execution: which operation identifier entered which queue, which worker claimed it, which authorization and dependency checks were current, and whether cancellation or expiry intervened. Third is outcome: which side effects were committed, which result was returned, and whether the terminal state is still authoritative.

Those joins are easy to lose. A gateway might generate the 202 while a different service owns the queue. The operation URL might identify a tenant-relative job whose meaning changes under another credential. A retry might receive the same acceptance response while referring to the same job, or create a second job when idempotency is absent. A worker can start after the requesting principal has lost authority. A terminal “succeeded” flag can be written before a downstream effect becomes observable.

None of these possibilities makes 202 defective. Asynchronous acceptance is valuable precisely because a connection need not stay open for a long-running process. The discipline is to preserve the response as acceptance evidence and obtain later evidence for later claims.

The useful evidence object is an asynchronous-operation receipt. It binds the request method, target and body digest to the authenticated principal, authorization epoch, idempotency key, observation point, 202 response, operation identifier and authoritative monitor URI. It then records queue admission, worker claim, fresh authorization and dependency checks, cancellation state, side-effect identifiers, terminal result, observation time and the decision that consumed that result.

Sources

RFC 9110 — HTTP Semantics, 202 Accepted; RFC 7240 — Prefer Header for HTTP.