HTTP 102 Processing

HTTP 102 Processing describes how the server is handling the request. Use it to predict client, cache, crawler, and monitoring behavior.

Try it (live endpoint)

Response includes the status code, standard headers (including Content-Type), and a small diagnostic JSON body describing the request and returned status.

curl -i "https://httpstatus.com/api/status/102"
Try in playground

Meaning

The server has received and is processing the request, but no response is available yet. Used in WebDAV to prevent client timeouts on long operations.

What it guarantees
  • An interim response was provided before the final response.
What it does NOT guarantee
  • The request has succeeded or failed.
  • Clients should treat this as a final outcome.

When to use this status

  • Use only when it accurately describes the outcome for clients and tooling.

When NOT to use this status (common misuses)

Critical headers that matter

Tool interpretation

Browsers
Treats as success; caches/revalidates based on headers and validators.
API clients
Deserializes per Content-Type; conditional requests use validators when implemented.
Crawlers / SEO tools
Indexes depending on headers and canonical stability; caches behavior via validators and cache directives.
Uptime monitors
Typically marks success; advanced checks may flag header anomalies or latency.
CDNs / reverse proxies
Caches/revalidates based on Cache-Control, ETag, and Vary; compression and content-type affect behavior.

Inspector preview (read-only)

On this code, Inspector focuses on semantics, headers, and correctness warnings that commonly affect clients and caches.

Signals it will highlight
  • Status semantics vs method and body expectations
  • Header sanity (Content-Type, Cache-Control, Vary) and evidence completeness
Correctness warnings
No common correctness warnings are specific to this code.

Guided Lab outcome

  • Reproduce HTTP 102 Processing using a controlled endpoint and capture the full exchange.
  • Practice distinguishing status semantics from transport issues (redirects, caching, proxies).

FAQ

Should clients retry on HTTP 102?
Usually no—treat it as a successful final response unless your domain requires revalidation.
Is HTTP 102 cacheable?
Generally should not be cached unless explicitly intended; use Cache-Control to prevent sticky failures.
Which headers matter most for HTTP 102?
Content-Type and Cache-Control are the baseline. Some codes also require Location, WWW-Authenticate, or Retry-After.
How does this affect monitoring?
Server errors typically page based on rate/threshold; enrich with upstream attribution.
How does this affect crawlers/SEO?
SEO impact is driven mostly by cacheability, canonical stability, and content correctness.
What should error responses include?
If a body is returned, keep it consistent and typed via Content-Type.

Client expectation contract

Client can assume
    Client must NOT assume
    No common correctness warnings are specific to this code.
    Retry behavior
    Retries are generally unnecessary; treat as final unless domain rules require revalidation.
    Monitoring classification
    Server error
    Use payload and header checks to avoid false positives; cacheability depends on Cache-Control/ETag/Vary.

    Related status codes

    101 Switching Protocols
    The server is switching protocols as requested by the client via the Upgrade header (e.g., upgrading to WebSocket).
    103 Early Hints
    Used to return preliminary response headers (typically Link headers for preloading resources) before the final HTTP response.