Runs in your browser. Your files and text never leave your device - nothing is uploaded.
1xx Informational
What it means
The server has received and is processing the request, but no response is available yet (WebDAV).
| Property | Detail |
|---|---|
| Status class | 1xx Informational |
| Defined in | RFC 2518, Section 10.1 — RFC 4918 (2007) removed 102 from the WebDAV specification because few implementations used it, but the IANA status code registry still lists it with a reference to RFC 2518. |
| Cacheable by default | No. 1xx responses are interim, and RFC 9111 only lets a cache store a final response. |
| Who needs to act | Nobody. The client simply keeps waiting for the final response. |
What does HTTP 102 Processing mean?
HTTP 102 Processing is an interim WebDAV response meaning the server has received the full request and is still working on it. It was defined in RFC 2518 to stop clients timing out during long operations, then dropped from RFC 4918 for lack of implementation. The final status code follows when the work finishes.
How 102 Processing works
RFC 2518 told servers to send 102 when a method was likely to take longer than about 20 seconds, which in practice meant WebDAV operations such as COPY, MOVE or DELETE on a large collection with Depth: infinity. Each 102 tells the client the request is alive, so it does not give up and retry. Because RFC 4918 later removed the code, support is patchy. RFC 9110 lets a client ignore any 1xx response it does not expect, so a 102 is no guarantee that a client will keep waiting, and a short client timeout can still cut the request off. Most modern APIs avoid holding a request open that long in the first place.
Example 102 request and response
COPY /projects/archive/ HTTP/1.1
Host: dav.example.com
Destination: https://dav.example.com/backup/archive/
Depth: infinity
HTTP/1.1 102 Processing
HTTP/1.1 201 CreatedThe 102 is only a progress signal. The 201 Created at the end, meaning the copy produced a new collection, is the real result of the request.
When servers send 102 Processing
- A WebDAV server copying, moving or deleting a large directory tree.
- Any long-running request on a server that still implements the RFC 2518 behaviour.
How to handle 102 Processing
If you build a client
- Treat 102 like any other interim response: keep the connection open and wait for the final status.
- Use a generous read timeout for WebDAV methods that act on whole collections.
If you design a new API
- Prefer 202 Accepted plus a status URL the client can poll, which works through every proxy and client library.
- If a request genuinely has to stay open, stream progress in the response body rather than relying on 102.
Related status codes
- 202 Accepted: The usual modern replacement: accept the job, return at once, and let the client poll for the result.
- 103 Early Hints: The interim code still in active use, which carries preload hints rather than a progress signal.
- 100 Continue: An interim response sent before the body is uploaded, not while the server is working.
Frequently asked questions
The server has received and is processing the request, but no response is available yet (WebDAV).
Sent to prevent a client from timing out while the server works on a long-running request.
Informational only - wait for the final response.
Rarely. RFC 4918 removed it from the WebDAV specification for lack of implementation, although the IANA registry still lists it. Treat it as legacy: clients should tolerate it, and new services should not depend on it.
Sources
Other 1xx Informational codes
Reviewed by Raja Jahangir · Last reviewed: October 7, 2026