WebUtils
EN

Developer Workflow

Inspect HTTP response headers before debugging APIs

Learn how to capture and inspect response headers from curl, browser DevTools, API clients, or CDN logs before changing cache, CORS, or security settings.

Open Http Header Parser

Problem

HTTP headers explain a lot of production failures, but copied header blocks are often noisy. A response may include duplicate Set-Cookie lines, cache rules from a CDN, CORS headers from a proxy, and security headers from middleware. If you inspect only the body or status code, you can miss the setting that actually controls browser behavior.

When to use this

  • A browser request fails because of CORS, mixed credentials, or missing preflight response headers.
  • 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 response headers from curl, DevTools, an API client, and production logs.

Steps

  1. Step 1

    Capture the raw headers

    Copy the full response header block from browser DevTools, `curl -I`, an API client, a CDN log, or server logs. Keep the status line if it is available.

  2. Step 2

    Parse before editing config

    Paste the block into `HTTP Header Parser` to normalize names, preserve values, and separate cache, CORS, content, security, request, and response header groups.

  3. Step 3

    Check duplicate headers

    Review duplicates such as `set-cookie`, `vary`, `cache-control`, or repeated `access-control-*` values. Some duplicates are valid, but accidental duplicates often explain confusing browser behavior.

  4. Step 4

    Follow the failing symptom

    For stale content, start with cache headers. For browser blocked requests, inspect CORS headers. For login or authorization failures, compare redirects, cookies, and token-related request details.

  5. Step 5

    Compare against the target URL

    Use `URL Parser` and `Query String Parser` for redirect or callback URLs, then keep the parsed header summary with your debugging notes.

Example

CORS and cache headers from a production API

Input

HTTP/2 200
content-type: application/json; charset=utf-8
cache-control: public, max-age=3600
access-control-allow-origin: https://app.example.com
vary: origin, accept-encoding
strict-transport-security: max-age=31536000; includeSubDomains

Output

Start line: HTTP/2 200
Total headers: 5
Cache headers: cache-control, vary
CORS headers: access-control-allow-origin
Security headers: strict-transport-security

Common mistakes

Only checking the response body

A JSON body can look correct while cache, CORS, cookie, or security headers still make the browser reject or reuse the response.

Ignoring where the header was added

Headers may come from application code, framework middleware, a CDN, a reverse proxy, or hosting defaults. Compare environments before changing the app.

Treating every duplicate as a bug

`set-cookie` commonly appears multiple times. Review the header name and behavior before deleting duplicates blindly.

FAQ

Should I paste private cookies or tokens?

Redact session IDs, tokens, API keys, and user identifiers before sharing screenshots or debugging notes. Local parsing is private, but copied output can still expose secrets.

Can response headers explain CORS errors?

Yes. Browser CORS failures often depend on `access-control-allow-origin`, `access-control-allow-credentials`, allowed methods, allowed headers, and preflight responses.

Why do curl and browser headers differ?

They may use different request headers, credentials, redirects, protocols, or caches. Compare the exact URL and request context before assuming the server changed.