102 - Processing

What Does Processing Mean?

Originally defined in RFC 2518, 102 was a "Keep-Alive" signal. It allowed servers to tell clients "I am still working" during operations that could take minutes. However, RFC 9110 deprecated it because holding an HTTP connection open with interim responses is unreliable in modern distributed systems. Today, encountering 102 usually indicates legacy WebDAV integrations or misconfigured proxies attempting to prevent 504 Gateway Timeouts incorrectly.

Common Causes

• -Legacy WebDAV Operations: Long-running COPY, MOVE, or LOCK requests on old file servers.
• -Interim Response Injection: A proxy server (like an older HAProxy or Nginx setup) emitting 102 to keep a client connection alive instead of managing timeouts properly.
• -Incompatible Client Libraries: Modern fetch-based clients (like Axios or Fetch API) often fail to expose 1xx interim codes, causing them to hang until the final status arrives, potentially timing out regardless.
• -Middleware Logic Errors: A backend service incorrectly using 102 to signal "Work in Progress" instead of using the modern 202 Accepted pattern.

How to Fix Processing

1. 1Upgrade to 202 Accepted: If you control the API, stop using 102. Return 202 Accepted immediately with a Location header for status polling.
2. 2Check Proxy Buffering: Ensure intermediate proxies do not "swallow" interim 1xx responses. If they buffer the whole response, the 102 benefit is lost.
3. 3Implement Client-Side Wait: If consuming a 102-emitting server, ensure your HTTP client is configured to "wait and continue" upon receiving interim responses.
4. 4Verify WebDAV Modules: On Apache or Nginx servers, audit the mod_dav or ngx_http_dav_module settings if 102 is appearing unexpectedly.

Step-by-Step Diagnosis for Processing

1. 1Confirm the source: Use curl -v to see if the 102 arrives from the origin or an intermediate proxy.
2. 2Identify the operation: Is it a standard GET/POST or a WebDAV-specific method like COPY or MOVE?
3. 3Measure the gap: Check how many 102 responses are sent before the final 200/201. If the gap is >30s, the client might drop the connection.
4. 4Inspect the "Server" header: Confirm if the backend is a known legacy system (e.g., old IIS or Apache versions with WebDAV).

curl -v -X COPY https://legacy.dav-server.com/large-archive \
     -H "Destination: /backup/archive"
# Look for interim response:
# < HTTP/1.1 102 Processing
# (Wait...)
# < HTTP/1.1 201 Created

// Instead of holding with 102, return 202
export async function POST(req) {
  const jobId = await startAsyncJob();
  return new Response(JSON.stringify({ jobId }), {
    status: 202,
    headers: { 'Location': `/api/jobs/${jobId}` }
  });
}

How to Verify the Fix

• -Verify that long operations now return a 202 Accepted with a trackable job ID.
• -Confirm that the client no longer hangs indefinitely or fails with an "Unexpected Status" error.
• -Ensure the final resource state (e.g., the copied file) is accurate after the 102 handshake completes.

How to Prevent Recurrence

• -Migrate to Async Workflows: Design API endpoints to be asynchronous by default for any task exceeding 5 seconds.
• -Client Middleware: Add a handler to your HTTP client to log 1xx informational responses for better observability.
• -Avoid Connection-Holding: Never rely on keeping an HTTP request open for minutes; use Webhooks or Polling instead.
• -Pro-tip: 102 is essentially a "Zombie Code." If you see it in a modern REST API, it is almost always a sign of technical debt that needs refactoring to 202.

Related Errors

Decision Support

Official References

• -MDN Web Docs: 102 Processing
• -RFC 9110: HTTP Semantics
• -RFC 2518 Section 10.1 (Deprecated by RFC 9110)
• -HTTP Official Documentation