HTTP Headers

Why it matters

Many defects live only in headers. A correct JSON body labelled Content-Type: text/html breaks clients that trust the label. A personal profile sent with Cache-Control: public may be stored by a shared cache, such as a CDN (content delivery network), and served to the next user. A session cookie without Secure may travel over unencrypted HTTP. Each time, the screen looks right and the UI test passes.

Headers also explain failures fast: Content-Type why a body does not parse, WWW-Authenticate which authentication a refused call expected, Cache-Control and Age (how many seconds old a cached copy is) why a fixed page still looks old.

How headers are written and read

Field names are case-insensitive: Content-Type and content-type are the same header, and HTTP/2 and HTTP/3 send every name in lowercase, which is why DevTools often shows content-type. Whether a value is case-sensitive depends on the header: media types such as application/json are not; access tokens and cookie values are.

A header may appear more than once. For list-valued headers such as Accept, a recipient may join the lines into one comma-separated line; RFC 9110 names Set-Cookie as the exception: one cookie per line, never merged. Headers fall into groups:

• Request headers describe the client and what it wants: Host (required in HTTP/1.1), User-Agent, Accept, Accept-Language, Authorization, Cookie.
• Response headers describe the answer: Set-Cookie, Location, WWW-Authenticate, Retry-After, Server.
• Content headers describe the body in either direction: Content-Type, Content-Length, Content-Encoding. Cache-Control also works both ways, with a different meaning in each.

Try it: Request Header Inspector Try it: HTTP Headers Parser

Five headers in almost every test

The exchange below saves a customer's preferred language on a test shop. Each of the five headers answers a different question.

PUT /api/v1/me/preferences HTTP/1.1
Host: test.shop.example.com
Part 1:1Content-Type: application/json
Part 2:2Accept: application/json
Part 3:3Authorization: Bearer eyJhbGciOi...
Content-Length: 18

{"language": "ar"}

HTTP/1.1 200 OK
Part 1:1Content-Type: application/json; charset=utf-8
Content-Length: 55
Part 4:4Cache-Control: no-store
Part 5:5Set-Cookie: lang=ar; Path=/; Max-Age=31536000; Secure

{"language": "ar", "updatedAt": "2026-10-01T09:30:00Z"}

• Content-Type: the media type of this message's body, with optional parameters such as charset. The receiver parses the body by it, so it must match the bytes; a server that does not accept the format should answer 415 Unsupported Media Type.
• Accept: the media types the client will take, optionally weighted (q=0.8). If none is available, RFC 9110 lets the server answer 406 Not Acceptable or ignore the header and send its default; the contract should say which.
• Authorization: a scheme and credentials, such as Bearer <token> (a token issued at sign-in) or Basic <credentials> (user name and password joined by a colon). Missing or invalid credentials get 401 Unauthorized, which RFC 9110 requires to carry a WWW-Authenticate header. Basic credentials are Base64-encoded, not encrypted: anyone who sees them can read them.
• Cache-Control: directives for caches (RFC 9111). max-age=600: fresh for 600 seconds, so a cache may reuse it without asking the server. no-cache: may be stored, but must be revalidated before each reuse. no-store: must not be stored. private: only a private cache, such as the browser, may store it. The HTTP caching lesson goes deeper.
• Set-Cookie: asks the browser to store a cookie, which it returns in the Cookie header of later matching requests. Attributes such as Max-Age, Secure and HttpOnly control how long it lives, where it goes and who can read it; the cookies and sessions lesson tests them.

PUT /api/v1/me/preferences HTTP/1.1
Host: test.shop.example.com
Content-Type: application/json
Accept: application/json
Authorization: Bearer eyJhbGciOi...
Content-Length: 18

{"language": "ar"}

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Content-Length: 55
Cache-Control: no-store
Set-Cookie: lang=ar; Path=/; Max-Age=31536000; Secure

{"language": "ar", "updatedAt": "2026-10-01T09:30:00Z"}

Try it: Content-Type Validator Try it: HTTP Header Builder

What to test in headers

Headers are part of the contract, so they belong in the test basis and the expected results.

• Response checks: the documented Content-Type, with a body that really is in that format; Location after 201 Created if the contract promises it; Cache-Control: no-store on personal data and credentials; the agreed attributes on every Set-Cookie.
• Request tests, one change at a time: no Authorization or an expired token (401 with WWW-Authenticate); JSON sent as Content-Type: text/plain (415, or the documented 400); an Accept format the API lacks (406, or the documented default). A duplicated header or a huge value may get 400 or 431 Request Header Fields Too Large; a 500 or a crash is a defect.
• Leaks and security headers: Server: Apache/2.4.41 (Ubuntu) or X-Powered-By: PHP/7.4.3 tell attackers which versions to look up; the OWASP HTTP Headers Cheat Sheet recommends removing X-Powered-By and removing Server or giving it a non-informative value. Check the agreed security headers, such as Strict-Transport-Security (it tells browsers to reach the site over HTTPS only), only on sites you own or have written permission to test.

Try it: API Header Validator Try it: Security Header Analyzer

Worked example: a profile response

A tester checks the profile endpoint of a shop's web app on the test environment. The status is 200 and the body is right, so the UI test passes, yet the raw exchange holds four header defects, each in its own report because each may be fixed in a different place: application code, session settings or web server configuration.

• Content-Type: text/html on JSON: clients that follow the header may not parse it as JSON, and a browser renders it as HTML, a script injection risk once a field holds user input. Expected: application/json.
• Cache-Control: public, max-age=3600 on personal data: a shared cache such as a CDN or a company proxy may keep the profile for an hour and serve it to someone else. Expected: no-store.
• Set-Cookie sets the session cookie again without Secure and HttpOnly: it may travel over unencrypted HTTP and page scripts can read it. Expected: the agreed session cookie attributes.
• Server and X-Powered-By reveal exact versions. Expected: removed or generic.
• After the fixes, confirmation testing repeats the request and compares the headers, and the four checks join the API regression suite.

GET /api/v1/me HTTP/1.1
Host: test.shop.example.com
Accept: application/json
Cookie: sid=9f2c41d7e0

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 62
Cache-Control: public, max-age=3600
Set-Cookie: sid=9f2c41d7e0; Path=/
Server: Apache/2.4.41 (Ubuntu)
X-Powered-By: PHP/7.4.3

{"id": 58, "name": "Test User", "email": "user58@example.com"}

Try it: HTTP Headers Parser Try it: Cache Header Analyzer Try it: Cookie Analyzer

Frequently asked questions

References

• RFC 9110: HTTP SemanticsIETF · 2022The meaning of HTTP methods, header fields, status codes and content negotiation, independent of the wire version.
• RFC 9111: HTTP CachingIETF · 2022How Cache-Control, Expires, ETag and validators decide whether a response may be stored and reused.
• OWASP Cheat Sheet Series: HTTP HeadersOWASP FoundationWhich security headers to send (HSTS, CSP, X-Content-Type-Options, frame protection) and which to remove (Server, X-Powered-By).
• HTTP headers — MDNMDN Web Docs (Mozilla)Reference for request and response headers: syntax, directives and browser support.