Headers

The Headers tab displays all HTTP headers returned by the server. Headers are organized into three sections: General Headers, CORS, and Caching. This organization makes it easy to find specific headers without scrolling through a long list.

General Headers

General headers include all response headers except the ones that are broken out into the CORS and Caching cards. Inside this block, entries are sorted by a small built-in priority list so the most commonly inspected headers surface first: content-type, content-length, content-encoding, date, server, connection. Any header not in this list appears below those six in the order the server returned it.

The table below lists frequently encountered headers as examples — it is not the full priority list, and you may see many other headers depending on what the server returns.

HeaderDescription
content-typeMIME type of the response body (e.g., application/json)
content-lengthSize of the response body in bytes
content-encodingCompression algorithm used (e.g., gzip, br)
serverServer software information
dateDate and time the response was generated
set-cookieCookies to store (shown in detail in Cookies tab)
x-request-idUnique identifier for debugging/tracing
Smart multi-line copy: Individual header keys and values are selectable — you can copy any single value directly. If you drag-select across several rows in the General Headers section and copy, Atrahasis reformats the selection into one key\tvalue pair per line (tab-separated), so the clipboard content pastes cleanly into a spreadsheet or text editor. This smart copy handler is attached only to the General Headers block; selections inside the CORS and Caching cards copy verbatim.

CORS (Cross-Origin Resource Sharing)

CORS headers control how browsers share resources between different origins. This section only appears if the response contains CORS headers.

HeaderPurposeExample Value
Allow-OriginOrigins allowed to access the resource*, https://example.com
Allow-MethodsHTTP methods allowed for cross-origin requestsGET, POST, PUT, DELETE
Allow-HeadersRequest headers allowed in cross-origin requestsContent-Type, Authorization
Allow-CredentialsWhether credentials (cookies, auth) are allowedtrue, false
Expose-HeadersHeaders that browsers can access from responseX-Request-Id, X-Rate-Limit
Max-AgeHow long preflight results can be cached (seconds)86400 (1 day)
Visual Display

CORS headers are displayed in a card format with parsed values for easy reading:

Allow-Originhttps://example.com
Allow-Methods
GETPOSTPUTDELETE
Allow-Headers
Content-TypeAuthorization
Note: CORS headers are set by the server. If you're seeing CORS errors in your browser, the server needs to include these headers in its response.

Caching

Caching headers control how responses are stored and reused. This section only appears if the response contains caching-related headers.

HeaderPurpose
Cache-ControlPrimary caching directives (parsed into individual badges)
ETagVersion identifier for conditional requests
Last-ModifiedWhen the resource was last changed
ExpiresDate after which the response is stale (legacy)
AgeHow long the response has been in cache (seconds)
Cache-Control Directives

The Cache-Control header is automatically parsed and displayed as individual badges. Atrahasis does not filter or rewrite directives — whatever the server emits ends up as a badge, including directive=value pairs such as max-age=3600. The table below is a quick reference to the most common HTTP/1.1 directives you will encounter; other directives (for example no-transform, stale-while-revalidate, or proxy-revalidate) appear the same way when the server returns them.

Cache-Control
publicmax-age=3600must-revalidate
DirectiveMeaning
publicCan be cached by browsers and CDNs
privateCan only be cached by browsers, not CDNs
no-cacheMust revalidate before using cached version
no-storeDo not cache at all
max-age=NCache is fresh for N seconds
s-maxage=NMax age for shared caches (CDNs)
must-revalidateMust check server when stale
immutableContent will never change
Conditional Requests with ETag

ETags enable conditional requests to save bandwidth:

  1. Server returns response with ETag: "abc123"
  2. Client caches the response with the ETag
  3. Next request includes If-None-Match: "abc123"
  4. If unchanged, server returns 304 Not Modified (no body)
  5. If changed, server returns new response with new ETag

Section Visibility

The CORS and Caching sections are context-aware and only appear when relevant:

CORS Section Shows When
  • Access-Control-Allow-Origin is present
  • Access-Control-Allow-Methods is present
  • Access-Control-Allow-Headers is present
  • Any other Access-Control-* header is present
Caching Section Shows When
  • Cache-Control is present
  • ETag is present
  • Last-Modified is present
  • Expires is present
  • Age is present
BodyCookies