Response headers describe the body, tell caches how long to keep it and switch on browser security features. You set them in your server or CDN configuration.
| Header | Purpose and example |
|---|---|
| Content-Type, Content-Encoding | Body format and compression (br, gzip) |
| Content-Disposition | Download: attachment; filename="a.pdf" |
| Cache-Control | Caching: max-age=31536000, immutable |
| ETag, Last-Modified, Vary | Validators for 304; headers that pick a variant |
| Location, Retry-After | Redirect target; wait time for 429/503 |
| Set-Cookie | id=9f2c; Secure; HttpOnly; SameSite=Lax |
| Access-Control-Allow-Origin | Origins that may read it (crossorigin) |
| Strict-Transport-Security | HTTPS only: max-age=63072000 |
| Content-Security-Policy | Allowed sources for scripts etc. (Content Security Policy) |
| X-Content-Type-Options | nosniff: never guess the type |
| Link | Early hints: </app.css>; rel=preload; as=style |
Older references list headers that are now useless or harmful. X-XSS-Protection is deprecated and can itself open XSS holes; use CSP instead. X-Frame-Options still blocks framing, but its ALLOW-FROM value makes browsers ignore the whole header, so use CSP frame-ancestors. Expires is ignored when Cache-Control: max-age is present, and RFC 9111 obsoleted Warning. Finally, strip version numbers from Server and drop X-Powered-By: they only help attackers find vulnerable software.