Skip to main content
HTTP headers are the metadata for web requests and responses — like the details you write on an envelope (sender, recipient, date, priority). They’re simple key-value pairs separated by a colon and tell servers and clients how to process a message: what format is expected, how responses should be cached, what security policies apply, and more. Quick example — basic request headers:
Host is the key and example.com is the value. Types of headers and where they fit
  • General headers: apply to both requests and responses (metadata about the message).
  • Request headers: sent by the client to describe the request and the client’s capabilities.
  • Response headers: sent by the server to describe the response and the server.
  • Security, Authentication, Caching, CORS, Proxy, and Custom headers: specialized categories for specific concerns.
A presentation slide titled "Types of HTTP Headers" with two colored boxes labeled "General Headers" and "Request/Response Headers." The request/response box lists examples: Security, Authentication, Caching, CORS, Proxy, and Custom headers.
General headers
  • Used in both requests and responses to convey message metadata (server name, connection directives, status, etc.).
Request headers
  • Sent by the client to tell the server about the request and client capabilities.
  • Common headers: Accept, Accept-Encoding, Accept-Language, User-Agent, Cookie.
  • HTTP/2 uses pseudo-headers (prefixed with :) such as :method, :path, :scheme, and :authority.
Example request (HTTP/2 pseudo-headers plus common headers):
  • User-Agent: identifies browser and platform; useful for analytics and troubleshooting.
  • Accept-Language: informs the server of preferred languages for content negotiation.
Response headers
  • Sent by the server to describe the response and server characteristics.
  • Common examples: Content-Type, Date, cache headers, and security headers.
Example response headers (Cloudflare + cache metadata):
Caching headers (overview)
  • Improve performance and reduce origin load by controlling how clients and intermediaries cache content.
  • Key headers: Cache-Control, Expires, ETag, Age, Vary.
Example showing caching metadata (response + request):
  • ETag: unique identifier for a resource version; used with If-None-Match for conditional requests (304 Not Modified).
  • X-Cache: indicates CDN/proxy cache status (HIT, MISS, BYPASS).
Security headers
  • Protect applications from XSS, clickjacking, protocol downgrades, and other threats.
  • Common security headers: Content-Security-Policy, X-Content-Type-Options, X-Frame-Options or frame-ancestors, Strict-Transport-Security, Referrer-Policy, Permissions-Policy.
Example response headers (Gmail-like CSP + security headers):
Table — common security headers and purpose Authentication headers
  • Used to authenticate clients to servers.
  • Examples: Authorization: Basic <base64>, Authorization: Bearer <token>.
Example request with Basic auth:
  • Note: Basic auth is simply base64 of user:password — do not send credentials over plain HTTP. Use Authorization: Bearer <token> for token-based flows (OAuth, JWTs).
CORS (Cross-Origin Resource Sharing)
  • CORS headers let servers control which external origins can access resources and what HTTP methods/headers are allowed in cross-origin requests.
A slide titled "CORS Header" showing a simple diagram of a webpage, a globe/network and servers with arrows labeled "Retrieves data" and "Includes CORS headers." It illustrates that CORS controls resource requests between different domains to protect data.
Example OPTIONS preflight response:
Table — key CORS headers Note: CORS is an application-level decision and often requires coordinating backend and frontend domains for safe configuration. Proxy headers
  • When requests traverse proxies, CDNs, or load balancers, these headers preserve original client information:
    • X-Forwarded-For: originating client IP + proxy chain (comma-separated).
    • X-Forwarded-Host: original Host header.
    • X-Forwarded-Proto: original protocol (http or https).
    • X-Forwarded-Server: hostname of the proxy that forwarded the request.
    • X-Real-IP: single client IP when there’s only one proxy.
Example environment-like listing showing typical forwarded headers:
  • Useful for logging, rate-limiting, geo-based decisions, and for upstream services that need the original client context.
Custom headers
  • Applications and intermediaries often add non-standard headers for tracing, metadata, or feature flags: X-Custom-Header, X-Request-ID, etc.
Example request with a custom header:
NGINX built-in variables
  • NGINX exposes built-in variables (prefixed with $) for dynamic behavior in configurations.
Common NGINX variables:
  1. $remote_addr — client IP address
  2. $remote_port — client source port
  3. $server_addr — NGINX server IP address
  4. $request — full request line (e.g., GET /index.html HTTP/1.1)
  5. $uri — current URI path without args (e.g., /index.html)
  6. $request_uri — full request including args (e.g., /index.html?user=Anthony)
  7. $request_method — request method (e.g., GET, POST)
  8. $args — query string (e.g., id=1234&name=example)
  9. $http_<header_name> — incoming HTTP header (e.g., $http_user_agent)
  10. $http_referer — Referer header value
  11. $status — response status code (e.g., 200, 404)
  12. $upstream_addr — address of the upstream that handled the request
  13. $scheme — http or https
  14. $host — original Host header (domain)
  15. $ssl_protocol — TLS protocol used (e.g., TLSv1.2)
  16. $ssl_cipher — TLS cipher used
  17. $http_cookie — raw Cookie header from the client
You can combine variables to construct the original request URL:
Use cases: logging, conditional routing, header transformation, and forwarding client details to upstreams. NGINX example: sending headers and proxying
  • add_header sets headers on responses sent from NGINX to the client.
  • proxy_set_header sets or overrides headers on requests forwarded to upstream backends.
Example server block showing common headers and proxy directives:
  • In this configuration, requests for honda.cars.com are proxied to backend_upstream. proxy_set_header forwards client details to the upstream, and add_header supplies security/caching headers back to the browser.
  • Remember: HSTS (Strict-Transport-Security) is only meaningful when sent over HTTPS.
Final notes and best practices
  • HTTP headers are central to content negotiation, caching, security, authentication, and the flow of information across clients, proxies, and servers.
  • Never expose sensitive information in response headers (e.g., internal tokens, credentials).
  • Use secure defaults: enable CSP, set X-Content-Type-Options: nosniff, and prefer Strict-Transport-Security for HTTPS sites.
  • Use ETag/conditional requests and appropriate Cache-Control settings to optimize performance.
  • When behind proxies, rely on forwarded headers (X-Forwarded-*, X-Real-IP) to preserve original client context for logging and upstream logic.
  • Test header behavior locally and in staging: inspect requests and responses with browser dev tools, curl -v, or a local proxy (e.g., mitmproxy) to validate your configuration.
This lesson covered the common HTTP header types and examples for request, response, security, caching, CORS, proxy, and custom headers, plus useful NGINX variables and a sample configuration. Use these patterns to secure, optimize, and trace your web traffic.
Try these steps locally: configure response headers, set proxy headers in NGINX, and inspect requests and responses to observe effects on caching, security, and logging.

Watch Video