# 102 Processing

> https://http-status.org/docs/102

**Family:** 1xx Informational

## Rationale

Interim WebDAV response: the server is still processing the request and no final status is ready yet.

## In Plain Terms

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

## Description

The HTTP 102 Processing status code is an interim WebDAV response indicating that the server received the complete request and is still processing it, but no final response is ready yet. It was introduced in RFC 2518 but was removed from the current WebDAV standard (RFC 4918) and is considered deprecated. It retains niche use in some server implementations, but should be treated with caution given its deprecated status and limited client and proxy support. It is distinct from 202 Accepted, which hands work off for later completion instead of keeping the current request open.

## Server Perspective

### Usage
- 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

### Implementation
- 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

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

### Body
- Do not include a response body in a 102 response.

### 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

## Client Perspective

### Pitfalls
- Do not treat 102 as completion
- Do not retry a non-idempotent request just because 102 arrived and the final response has not appeared yet

## Examples

### WebDAV bulk property update

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

**Request:**
```
PROPPATCH https://api.example.test/folder/

<propertyupdate xmlns="DAV:">...</propertyupdate>
```

**Response:**
```
102 Processing
207 Multi-Status
Content-Type: application/xml; charset=utf-8

<multistatus xmlns="DAV:">...</multistatus>
```

### Large directory copy operation

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

**Request:**
```
COPY https://api.example.test/source-folder/
Destination: https://api.example.test/destination/
```

**Response:**
```
102 Processing
207 Multi-Status
Content-Type: application/xml; charset=utf-8

<multistatus xmlns="DAV:">...</multistatus>
```

## Related Codes

- [100 Continue](/docs/100.md)
- [202 Accepted](/docs/202.md)
- [207 Multi-Status](/docs/207.md)