102

Processing

1xx Informational

Back to list.md

ELI5

The server is saying, 'I’m still working on this. Don’t assume the request was lost just because it’s taking a while.'

Server perspective

Use 102 as an interim WebDAV response when processing is underway and the final status is not ready yet.

When to use

  • •Return 102 for long-running WebDAV methods that may otherwise look stalled
  • •Use it only after the full request has been received and you reasonably expect the operation to take noticeable time
  • •Use it before a later final response such as 207, 204, or an error
  • •Long-running WebDAV operations
  • •Deep COPY, MOVE, PROPFIND, or PROPPATCH work that may take noticeable time
  • •Operations touching many files or properties
  • •Situations where an interim response helps prevent client timeout assumptions

How to respond

  • •Send 102 only when the operation is genuinely still in progress and you want to keep the client from assuming the request was lost
  • •Follow it with a normal final response once processing completes

Headers to consider

  • •No status-specific header is required; the later final response carries the real outcome metadata.

Response body

  • •Do not include a response body in a 102 response.

Server-side pitfalls

  • •Do not use 102 as a substitute for a proper async job resource when your API contract is really 'accepted for later processing'; that is usually 202 Accepted
  • •Do not send 102 before the request has been fully received
  • •Do not leave the client without a later final response
  • •Typical REST-style async job APIs where 202 Accepted is the better contract
  • •Short operations that can simply return a final response
  • •As a replacement for the final success or error status
  • •General-purpose progress reporting outside the HTTP/WebDAV semantics you actually support
  • •New WebDAV-compatible services where long-running operations need to signal progress — 102 was removed from RFC 4918 (the current WebDAV standard) and has no normative standing; prefer 202 Accepted or a streaming progress design

Examples

WebDAV bulk property update

Request:PROPPATCH https://api.example.test/folder/ # Body <propertyupdate xmlns="DAV:">...</propertyupdate>
Response 1:102 Processing
Response 2:207 Multi-Status # Headers Content-Type: application/xml; charset=utf-8 # Body <multistatus xmlns="DAV:">...</multistatus>

The server signals that it is still working before returning the final per-resource results.

Large directory copy operation

Request:COPY https://api.example.test/source-folder/ # Headers Destination: https://api.example.test/destination/
Response 1:102 Processing
Response 2:207 Multi-Status # Headers Content-Type: application/xml; charset=utf-8 # Body <multistatus xmlns="DAV:">...</multistatus>

The server keeps the client informed that the lengthy WebDAV operation is still active.

References

Related Status Codes

100

Continue

Imagine calling ahead before mailing a very heavy package: 'Can you accept this?' The post office says yes, so you drive it over. That's 100 Continue — the server greenlit the request headers, so send the rest of the data.

202

Accepted

We got your request and we're working on it! We'll process it later, but don't wait around - check back later to see if it's done.

207

Multi-Status

I did multiple things for you - some worked, some didn't. Here's a detailed report of what happened to each item.

WebDAV