HTTP 102 Processing

What 102 Processing means

102 solved a real problem badly. A WebDAV method such as a deep PROPFIND or MOVE across a large collection can take minutes, and a client with a 30-second read timeout gives up long before the server finishes. 102 was a keep-alive ping: an interim response the server could emit to say “still working”. The trouble is that clients could not tell how long to keep waiting, and implementations were inconsistent enough that the mechanism was dropped rather than fixed.

What the spec says

102 was defined in RFC 2518 §10.1, the original WebDAV specification. RFC 2518 was obsoleted by RFC 4918, which deliberately does not define 102 — see the changes summary in RFC 4918 Appendix F. The IANA registry still lists 102 with RFC 2518 as its reference because registrations are not withdrawn when a specification is superseded. Treat it as historical: no current specification requires a client to understand it.

What actually causes it

If you see 102 today it is either an old WebDAV stack or someone reaching for it as a heartbeat on a slow endpoint. The second case does not work: HTTP clients that are not WebDAV-aware will either ignore the interim response or, worse, treat the connection as broken. If you need to tell a client that work is ongoing, the modern answer is to return 202 Accepted with a status URL it can poll, or to stream a chunked response so bytes keep flowing and the read timeout never fires.

How to debug it

Reproduce with a verbose WebDAV method and look for interim status lines before the final response:

curl -v -X PROPFIND -H 'Depth: infinity' \
-H 'Content-Type: application/xml' \
https://dav.example.com/collection/ 2>&1 | grep '^< HTTP'

Most client libraries hide 1xx responses entirely, so the absence of 102 in your application logs proves nothing. If a slow WebDAV operation is timing out, the fix is almost never to get 102 working — raise the client read timeout, reduce Depth, or split the operation. If you control the server and are tempted to emit 102, emit 202 and a polling endpoint instead; every HTTP client understands that without special support.

Working examples

curl

# Long-running WebDAV request; grep the raw status lines to catch interim ones.
curl -v -X PROPFIND \
  -H 'Depth: infinity' \
  -H 'Content-Type: application/xml' \
  --data '<?xml version="1.0"?><propfind xmlns="DAV:"><allprop/></propfind>' \
  https://dav.example.com/collection/ 2>&1 | grep '^< HTTP'

Python (requests)

import requests

# requests discards 1xx interim responses; you only ever observe the final status.
resp = requests.request(
    "PROPFIND",
    "https://dav.example.com/collection/",
    headers={"Depth": "1", "Content-Type": "application/xml"},
    data='<?xml version="1.0"?><propfind xmlns="DAV:"><allprop/></propfind>',
    timeout=120,  # raise the read timeout instead of relying on 102
)
print(resp.status_code)  # 207 Multi-Status on success

Node (fetch)

// node:http surfaces interim responses via the "information" event.
import http from "node:http";

const req = http.request(
  { host: "dav.example.com", path: "/collection/", method: "PROPFIND",
    headers: { Depth: "1", "Content-Type": "application/xml" } },
  (res) => console.log("final:", res.statusCode),
);
req.on("information", (info) => console.log("interim:", info.statusCode));
req.end('<?xml version="1.0"?><propfind xmlns="DAV:"><allprop/></propfind>');

Reference and tooling

The authoritative list of assigned status codes is theIANA HTTP Status Code Registry. For a searchable copy with the semantics summarised, use theHTTP status code reference on this site. To see exactly what a server is sending, theheader inspector shows the raw status line and response headers, and thecurl builder assembles the request flags for you.

102 Processing

Common causes at a glance