Inspect HTTP response headers before debugging APIs

Problem

Copied HTTP output can mix redirect hops, a final response, duplicate fields, and a response body. It can also contain session cookies, authorization values, client IPs, or API keys. Reading that text as one flat list can hide which hop set a value, while treating every duplicate or parser warning as a proven vulnerability can lead to the wrong fix.

Sources and standards

These authoritative references define the formats or security boundaries used in this workflow. Tool-specific verification is documented separately above.

• RFC 9110: HTTP Semantics

  RFC Editor / IETF

When to use this

• A browser request fails because of CORS, credentials, or a missing preflight response header.
• A CDN or browser keeps serving stale content after a deployment.
• A redirect, API request, or login callback works in one environment but not another.
• You need to compare raw headers captured by curl, DevTools, an API client, or production logs.
• A proxy or server reports duplicate Host, Content-Length, or Transfer-Encoding fields and you need a reviewable record.

Steps

1. Step 1

   Capture every response block

   Copy the raw status line and fields for each redirect and the final response. Preserve the blank line between blocks. A command such as `curl -D - -o /dev/null URL` records response headers without relying on HEAD behavior.

2. Step 2

   Remove secrets at the source

   Delete real cookies, bearer tokens, API keys, user identifiers, client IPs, and internal hostnames before sharing the capture. The parser works locally and masks recognized sensitive fields by default, but its name list is a safety aid rather than a complete secret scanner.

3. Step 3

   Parse within explicit limits

   Paste the capture into `HTTP Header Parser`. It separates valid start lines into at most 20 blocks, stops at the first body boundary, and accepts at most 500,000 UTF-8 bytes, 10,000 lines, 32,768 bytes per line, and 2,000 fields. Invalid names and control characters are skipped with warnings.

4. Step 4

   Classify duplicates before changing them

   Read repeated fields as expected repeats, review items, or conflicts. Multiple `set-cookie` and authentication challenge fields can be valid; conflicting Content-Length values, duplicate Host fields, and singleton pseudo-header repeats require closer investigation.

5. Step 5

   Investigate high-risk framing signals

   Conflicting Content-Length values or Transfer-Encoding together with Content-Length can matter at proxy boundaries. A parser finding is not proof of request smuggling or another exploit. Reproduce against the exact hop and compare how every intermediary interprets the message before assigning severity.

6. Step 6

   Verify the failing request and keep redacted evidence

   For CORS, capture both OPTIONS and the final request. For redirects, inspect each Location target. For cache or cookie problems, compare the same URL and request context across environments, then attach only the masked report to debugging notes.

Example

HTTP/1.1 302 Found
location: https://api.example.com/v2/items
set-cookie: route=example-token; Path=/; Secure; HttpOnly

HTTP/2 200
content-type: application/json
set-cookie: session=first-example; Path=/; Secure; HttpOnly
set-cookie: preference=compact; Path=/
content-length: 18
transfer-encoding: chunked

{"items":[1,2,3]}

Blocks: 2
Accepted fields: 7
Sensitive fields: 3, masked in the report
Duplicate set-cookie: expected repeat
High signal: Transfer-Encoding appears with Content-Length
Ignored trailing body lines: 1

Common mistakes

FAQ