HTTP Status Analyzer

Server assisted Validation

Paste a raw response (or fetch a public URL) to see the status class, semantics, required headers for that status (Location, Retry-After, WWW-Authenticate, Allow) and common mistakes.

Privacy: Processing happens in your browser where possible. Network checks are relayed through the Mutqan backend and are not stored.

How to use HTTP Status Analyzer

  1. Paste the raw HTTP response (status line, headers, blank line, body) or curl -i output — or switch to fetch mode and enter a public URL.
  2. If your paste has no status line, enter the code in the status field.
  3. Click "Analyze" to read the semantics, body and caching expectations for that status.
  4. Review the findings and companion-header table; fix the errors first, then the warnings.

HTTP Status Analyzer features

  • Explains the status class, meaning, typical use and testing hints for any code 100–599
  • Checks companion headers per status: Location, WWW-Authenticate, Allow, Retry-After, Content-Range, Proxy-Authenticate
  • Flags bodies on 204/304, missing Content-Type, invalid Retry-After, cacheable 5xx errors and JSON bodies that do not parse
  • Spots method/status mismatches such as 301 after POST or 200 with Location after a create
  • Accepts raw responses, curl -i output, header lists or a JSON object; or fetches a public URL without following redirects
  • Verdict (correct / questionable / incorrect) with a downloadable findings table

HTTP Status Analyzer example

401 without a challenge

Input:

HTTP/1.1 401 Unauthorized
Content-Type: text/html
Cache-Control: max-age=3600

Output:

Status: 401 Unauthorized (client error) · Verdict: Incorrect
High — WWW-Authenticate: 401 Unauthorized requires a WWW-Authenticate header. RFC 9110 requires at least one challenge.
Low — Content-Type: Error responses from APIs are easier to consume as application/problem+json.

Frequently asked questions about HTTP Status Analyzer

Which headers are required for which status?

301/302/303/307/308 need Location, 401 needs WWW-Authenticate, 405 needs Allow, 407 needs Proxy-Authenticate and 206 needs Content-Range. 429 and 503 should send Retry-After.

What input formats work?

A raw HTTP response (status line, headers, blank line, body), curl -i output, plain "Name: value" lines with the status code entered separately, or a JSON object with status and headers.

Does fetch mode follow redirects?

No — it returns the first response so you can inspect the redirect status and its Location header. The URL must be public.

Why does it complain about a body on 204?

RFC 9110 forbids a message body on 1xx, 204 and 304 responses; many clients fail or hang when one is present.

What is the difference between 401 and 403?

401 means authentication is missing or invalid and must include a WWW-Authenticate challenge; 403 means the caller is known but not allowed, so no challenge is needed.

Technical notes

Status semantics come from the shared HTTP knowledge base (RFC 9110 plus common vendor codes). Companion-header rules encode the "MUST"/"SHOULD" language of the RFC: required headers produce high-severity findings, recommended ones low-severity notes.

In fetch mode the relay is asked not to follow redirects so that a 301/302 and its Location header are analysed as returned; the relay still refuses private and loopback addresses.