Skip to main content
1xx Informational

102 Processing

The server has received and is processing the request, but no response is available yet.

Meaning & Description

The HTTP `102 Processing` informational status code indicates that the server has accepted the complete request but has not yet completed processing it.

Originally defined in RFC 2518 for WebDAV (Web Distributed Authoring and Versioning), this code was designed to prevent clients from timing out when a server takes a long time to perform complex file operations (like moving or copying deeply nested directory trees). The server can periodically send `102 Processing` responses to let the client know the connection is still alive.

> [!WARNING] > This status code was deprecated in RFC 9110 (2022). Modern APIs should use asynchronous processing (e.g., returning `202 Accepted` with a polling URL) rather than holding the connection open with 102 responses.

Common Causes

  • A WebDAV `PROPFIND`, `COPY`, or `MOVE` operation on a massive directory structure.
  • A long-running database query running behind a legacy proxy configured to emit 102 heartbeats.

How to fix a 102 error

  1. If your client times out despite receiving a 102, check if the client library supports 1xx interim responses.
  2. If you are a server developer, consider migrating from synchronous 102-based requests to asynchronous `202 Accepted` polling or WebSockets.
  3. Ensure reverse proxies (like Nginx or HAProxy) are not buffering the 102 responses, which defeats their purpose.

Browser & SEO Behaviour

Browser Behavior

Browsers ignore the 102 Processing interim response and continue waiting for the final response.

SEO Impact

No impact. Search engine crawlers do not perform long-running WebDAV operations.

CDN Behavior

CDNs usually buffer or ignore 102 responses. Many will drop the connection if the final response takes longer than their configured read timeout, regardless of 102 heartbeats.

Code Examples

Raw HTTP
PROPFIND /large-directory HTTP/1.1
Host: webdav.example.com
Depth: infinity

HTTP/1.1 102 Processing

[... 20 seconds later ...]

HTTP/1.1 207 Multi-Status
Content-Type: application/xml

<?xml version="1.0" encoding="utf-8" ?>
<d:multistatus xmlns:d="DAV:">...</d:multistatus>
Node.js (HTTP)
const http = require('http');

const server = http.createServer((req, res) => {
  // Emitting an interim 102 response (legacy approach)
  res.writeProcessing(); // Note: Not a standard Node.js method, requires manual socket writing
  req.socket.write('HTTP/1.1 102 Processing\r\n\r\n');
  
  setTimeout(() => {
    res.writeHead(200);
    res.end('Processing complete');
  }, 10000);
});
Python (Flask)
# Python WSGI servers (like Gunicorn/uWSGI) and frameworks (Flask/Django) 
# generally do not support sending multiple status codes (102 followed by 200) 
# on a single synchronous connection. 
# The recommended approach in Python is a Celery background task and a 202 response.

@app.route('/long-task', methods=['POST'])
def long_task():
    task = process_data.delay()
    return jsonify({"task_id": task.id}), 202
Go (net/http)
package main

import (
	"net/http"
	"time"
)

func handler(w http.ResponseWriter, r *http.Request) {
	// Go allows hijacking the connection to write raw HTTP if strictly necessary
	hijacker, ok := w.(http.Hijacker)
	if ok {
		conn, _, _ := hijacker.Hijack()
		defer conn.Close()
		conn.Write([]byte("HTTP/1.1 102 Processing\r\n\r\n"))
		
		time.Sleep(10 * time.Second)
		conn.Write([]byte("HTTP/1.1 200 OK\r\nContent-Length: 2\r\n\r\nOK"))
	}
}
curl
# curl handles 1xx informational responses automatically 
# and will wait for the final response without timing out.
curl -X PROPFIND -H "Depth: infinity" https://webdav.example.com/files/

Raw HTTP Response Example

HTTP Response
HTTP/1.1 102 Processing

HTTP/1.1 201 Created
Date: Mon, 23 May 2026 22:38:34 GMT
Content-Length: 0

Real-world Examples

Nextcloud / ownCloud: As platforms that heavily rely on WebDAV for file synchronization, they historically dealt with 102 responses for large directory copies.
Apache HTTP Server: The `mod_dav` module in Apache can generate 102 Processing responses during complex file operations.

Frequently Asked Questions

Should I use 102 Processing for my slow REST API endpoint?

No. The 102 status code is deprecated and heavily tied to WebDAV. For modern APIs, you should return a 202 Accepted status with a URL that the client can poll to check the status of the background job.

Why was 102 Processing deprecated?

It was deprecated in RFC 9110 because holding HTTP connections open for extended periods is inefficient, scales poorly, and is prone to being dropped by load balancers and firewalls. Asynchronous patterns are vastly superior.

Can I send multiple 102 Processing responses?

Yes, historically, a server could periodically send a 102 Processing response every few seconds as a heartbeat to prevent the client from dropping the connection before the final response was ready.

Did You Know?

Status code 102 is one of the rare status codes introduced by WebDAV (RFC 2518) that is an informational 1xx code; most WebDAV codes are 2xx or 4xx/5xx.

Many modern HTTP client libraries silently drop 1xx responses (other than 100 Continue) because they break standard request/response parsing expectations.

Implementing 102 responses often requires bypassing modern web frameworks and writing directly to the underlying TCP socket.

Developer Tips

  • If you are building a new system, completely ignore the existence of 102 Processing. Use WebSockets, Server-Sent Events (SSE), or a polling mechanism with 202 Accepted.
  • If a client application is timing out during a long operation, do not try to fix it by emitting 102s. Instead, increase the client-side timeout or refactor the endpoint to be asynchronous.
  • When debugging legacy WebDAV systems, use Wireshark or raw tcpdump rather than Chrome DevTools, as browser network tabs often hide 1xx interim responses.

Interview Questions

These are questions you might face in a backend or API design interview that touch on HTTP 102.

What was the original purpose of the 102 Processing status code?

It was designed for WebDAV to prevent client timeouts during very long file operations. The server could send interim 102 responses as heartbeats to let the client know it was still working.

Why is 102 Processing considered a bad practice in modern API design?

Holding an HTTP connection open synchronously for a long time consumes server threads and is fragile (proxies/firewalls often drop idle connections). Modern APIs should use asynchronous processing, returning a 202 Accepted immediately and letting the client poll for the result.

Common Interview Mistakes

  • Suggesting that 102 Processing is a good solution for a slow database query in a modern microservices architecture.
  • Confusing 102 Processing with 202 Accepted. 102 keeps the original connection open; 202 closes the connection immediately while work continues in the background.