102 Processing

RFC 2518, section 10.1, suggested sending 102 when a method would take longer than about 20 seconds, such as a COPY or DELETE on a large collection with Depth: infinity, and required a final response once the work finished. Go and Node still expose it (http.StatusProcessing, response.writeProcessing()), but most HTTP clients simply discard it like any unknown 1xx.

For new APIs, a long-running request is better modeled as 202 Accepted plus a status resource the client can poll, which survives proxies with short timeouts and dropped connections.

• Only for WebDAV-style clients that expect it, sent periodically during an operation that runs well past the client timeout.

Next.js route handlers and FastAPI cannot emit 1xx responses. Prefer 202 Accepted with a status URL for anything new.

app.post('/imports', async (req, res) => {
  // Interim "102 Processing" every 15 s while the import runs
  const timer = setInterval(() => res.writeProcessing(), 15_000);
  try {
    const result = await runLongImport(req);
    res.status(200).send(result);
  } finally {
    clearInterval(timer);
  }
});

mux.HandleFunc("POST /imports", func(w http.ResponseWriter, r *http.Request) {
	done := make(chan []byte)
	go func() { done <- runLongImport(r) }()
	for {
		select {
		case result := <-done:
			w.Header().Set("Content-Type", "application/json")
			w.WriteHeader(http.StatusOK)
			w.Write(result)
			return
		case <-time.After(15 * time.Second):
			w.WriteHeader(http.StatusProcessing) // interim 102, sent immediately
		}
	}
})

102 vs 202

202 ends the request right away and moves the waiting to a separate status resource; 102 keeps the original request open until the final answer.

102 vs 103

103 Early Hints is the modern 1xx browsers act on; it carries Link headers, while 102 carries no information beyond "still working".

Is 102 Processing deprecated?

Effectively yes. RFC 4918, which replaced RFC 2518 in 2007, removed it for lack of implementation. It remains in the IANA registry pointing to RFC 2518, so it is still a valid code, just rarely used.

Do browsers support 102 Processing?

Browsers accept and ignore it like any interim response; it does not keep fetch() from timing out on its own terms or show anything to the user. It was aimed at WebDAV clients.

What should I use instead of 102 for long requests?

Return 202 Accepted with a Location or link to a job resource and let the client poll it, or stream progress over Server-Sent Events or a WebSocket.