HTTP 101 Switching Protocols

HTTP 101 Switching Protocols 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/101"
Try in playground

Meaning

The server is switching protocols as requested by the client via the Upgrade header (e.g., upgrading to WebSocket).

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 101 Switching Protocols 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 101?
Usually no—treat it as a successful final response unless your domain requires revalidation.
Is HTTP 101 cacheable?
Generally should not be cached unless explicitly intended; use Cache-Control to prevent sticky failures.
Which headers matter most for HTTP 101?
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

    100 Continue
    The server has received the request headers, and the client should proceed to send the request body (used with Expect: 100-continue header).
    102 Processing
    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.