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.

Header	Description
content-type	MIME type of the response body (e.g., application/json)
content-length	Size of the response body in bytes
content-encoding	Compression algorithm used (e.g., gzip, br)
server	Server software information
date	Date and time the response was generated
set-cookie	Cookies to store (shown in detail in Cookies tab)
x-request-id	Unique identifier for debugging/tracing

Smart multi-line copy: Individual header keys and values are selectable, so 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.

Header	Purpose	Example Value
Allow-Origin	Origins allowed to access the resource	*, https://example.com
Allow-Methods	HTTP methods allowed for cross-origin requests	GET, POST, PUT, DELETE
Allow-Headers	Request headers allowed in cross-origin requests	Content-Type, Authorization
Allow-Credentials	Whether credentials (cookies, auth) are allowed	true, false
Expose-Headers	Headers that browsers can access from response	X-Request-Id, X-Rate-Limit
Max-Age	How 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.

Header	Purpose
Cache-Control	Primary caching directives (parsed into individual badges)
ETag	Version identifier for conditional requests
Last-Modified	When the resource was last changed
Expires	Date after which the response is stale (legacy)
Age	How 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, so 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

Directive	Meaning
public	Can be cached by browsers and CDNs
private	Can only be cached by browsers, not CDNs
no-cache	Must revalidate before using cached version
no-store	Do not cache at all
max-age=N	Cache is fresh for N seconds
s-maxage=N	Max age for shared caches (CDNs)
must-revalidate	Must check server when stale
immutable	Content will never change

Conditional Requests with ETag

ETags enable conditional requests to save bandwidth:

Server returns response with ETag: "abc123"
Client caches the response with the ETag
Next request includes If-None-Match: "abc123"
If unchanged, server returns 304 Not Modified (no body)
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

Body Cookies