102 Processing
An interim response indicating the server has accepted the request but has not completed it.
Usually happens because:
- ☑ Long-running WebDAV file operations on
- ☑ Server resetting client socket connection
🔍 Quick Checklist:
Meaning
The HTTP 102 Processing status code is an WebDAV extension used to inform the client that the server has accepted the complete request, but has not yet completed it and does not have a final status response ready yet.
Root Causes
- Long-running WebDAV file operations on network folders.
- Server resetting client socket connection timeout clock during complex calculations.
| Cause | Frequency |
|---|---|
| Long-running WebDAV file operations on | ⭐⭐⭐⭐⭐ |
| Server resetting client socket connection | ⭐⭐⭐⭐ |
Common Mistakes
- Assuming standard browsers support 102 Processing status codes dynamically.
- Failing to close the socket connection after final operations finish.
How to Fix
Framework-Specific Examples
Simulating interim processing status codes in Express middleware.
app.get('/dav', (req, res) => {
res.status(102).send();
});Server Configuration Examples
Configuring Nginx WebDAV extensions.
dav_methods PUT DELETE MKCOL COPY MOVE;Prevention
- Use WebSockets or EventSource streams instead of legacy WebDAV 102 status handlers.
- Ensure proxies do not buffer headers indefinitely.
Frequently Asked Questions (FAQ)
Q: Is 102 Processing deprecated?
Yes. It was defined in RFC 2518 for WebDAV but has been omitted from RFC 4918 updates, advising developers to use alternate polling mechanisms.
Q: Why would my client time out even after receiving a 102 status?
Many HTTP client libraries have hard-coded timeout limits (e.g. 30 seconds) that ignore informational 102 status code packet updates.
Q: What is WebDAV?
Web Distributed Authoring and Versioning (WebDAV) is a set of extensions to the HTTP protocol which allows clients to perform remote Web content authoring operations.
Q: Should I use 102 for standard REST API endpoints?
No. It is highly recommended to use asynchronous job queues with a status URL (returning 202 Accepted) instead of synchronous 102 blocks.