Understanding HTTP Headers

HTTP headers are core parts of the Hypertext Transfer Protocol (HTTP). They carry communication between web browsers and servers.

When you opened this blog post, your browser sent a few HTTP requests to GET the HTML, and received a response for each one. HTTP headers hold information about the request or response and give extra instructions to the server or browser.

Example

When you request a webpage in your browser, your headers may look like this:

1GET /blog/http-headers/ HTTP/1.1
2Accept: text/html, application/xhtml+xml, application/xml; q=0.9, mage/avif, image/webp, image/apng, */*; q=0.8, application/signed-exchange; v=b3; q=0.7
3Accept-Encoding:  gzip, deflate, br
4Accept-Language: en-US,en;q=0.9,ar;q=0.8,ru;q=0.7
5Cache-Control: no-cache
6Connection: keep-alive
7Host: mohammadshehadeh.com
8Pragma: no-cache
9Sec-Fetch-Dest: empty
10Sec-Fetch-Mode: navigate
11Sec-Fetch-Site: same-origin
12Upgrade-Insecure-Requests: 1
13User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36

In response, your browser may receive something like this:

1HTTP/1.1 200 OK
2Vary: RSC, Next-Router-State-Tree, Next-Router-Prefetch, Next-Url, Accept-Encoding
3x-nextjs-cache: HIT
4Cache-Control: no-store, must-revalidate
5Content-Type: text/html; charset=utf-8
6Content-Encoding: gzip
7Date: Sun, 11 Feb 2024 19:59:53 GMT
8Connection: keep-alive
9Keep-Alive: timeout=5
10Transfer-Encoding: chunked

Let's break down and explain each header

Request Headers

• Request Line

1GET /blog/http-headers/ HTTP/1.1

The request line. The client is making a GET request for the resource at /blog/http-headers/ using HTTP version 1.1.

• Accept

1Accept: text/html, application/xhtml+xml, application/xml; q=0.9, mage/avif, image/webp, image/apng, _/_; q=0.8, application/signed-exchange; v=b3; q=0.7

Lists the media types the client can accept, ordered by preference with quality values (q-values).

• Accept-Encoding

1Accept-Encoding: gzip, deflate, br

Tells the server which encodings the client supports for the response. Common values include gzip, deflate, and br (Brotli).

• Accept-Language

1Accept-Language: en-US,en;q=0.9,ar;q=0.8,ru;q=0.7

States the natural language and locale the client prefers.

• Cache-Control

1Cache-Control: no-cache

Controls caching. Here, "no-cache" means the client prefers a fresh response from the server over a cached one.

• Connection

1Connection: keep-alive

Sets whether the connection stays open (keep-alive) or closes after the current request/response.

• Host

1Host: mohammadshehadeh.com

Names the domain and port of the server the client wants to reach. If no port is given, the default for the service is implied (443 for HTTPS, 80 for HTTP).

• Pragma

1Pragma: no-cache

Kept for backward compatibility with HTTP/1.0. Here it indicates no-cache. It serves HTTP/1.0 caches that lack the HTTP/1.1 Cache-Control header.

• Upgrade-Insecure-Requests

1Upgrade-Insecure-Requests: 1

Signals that the client prefers a secure connection (HTTPS) when the server supports it.

• Sec-Fetch Headers

1Sec-Fetch-Dest: empty Sec-Fetch-Mode: navigate Sec-Fetch-Site: same-origin

• Sec-Fetch-Dest: The destination of the request. Here it's "empty."

• Sec-Fetch-Mode: How the request was initiated. Here it's "navigate," meaning navigation to a new browsing context.

• Sec-Fetch-Site: The site the request comes from. Here it's "same-origin."

• Origin

  The origin (scheme, hostname, and port) that started the request <scheme>://<hostname>:<port>

• User-Agent

1User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36

Identifies the client (browser) making the request, including its software, operating system, and version.

• Authorization

1Authorization: Bearer "token"

Sends credentials for authentication. It usually contains encrypted information.

• Cookie

1Cookie: name=value; sessionID=abc123

Sends previously-stored cookies back to the server.

• Access-Control-Request-Method

1Access-Control-Request-Method: POST

Sent by browsers in a preflight request to tell the server which HTTP method the actual request will use.

• Access-Control-Request-Headers

1Access-Control-Request-Headers: Content-Type, x-requested-with

Sent by browsers in a preflight request to tell the server which HTTP headers the actual request will use. The server answers this header with Access-Control-Allow-Headers.

Response Headers

• Status Line

1HTTP/1.1: 200 OK

Shows the server processed the request successfully.

• Vary

1Vary: RSC, Next-Router-State-Tree, Next-Router-Prefetch, Next-Url, Accept-Encoding

Lists the parts of the request, beyond the method and URL, that shaped the response. It's most often used to build a cache key during content negotiation.

• Date

1Date: Sun, 11 Feb 2024 19:59:53 GMT

The date and time the server sent the response. It helps determine how fresh the response is.

• Keep-Alive

1Keep-Alive: timeout=5

Gives the keep-alive timeout: how long the connection stays open for future requests.

• Transfer-Encoding

1Transfer-Encoding: chunked

Shows the response uses chunked transfer encoding, sending the response in a series of chunks. This is useful for streaming content.

Security Headers

• Strict-Transport-Security (HSTS): Instructs the browser to only access the server over HTTPS.

Users often reach the HTTP version of a site first, then get redirected to HTTPS. The Strict-Transport-Security header tells the browser to never load the site over HTTP and to convert every HTTP attempt to an HTTPS request instead.

• Content-Security-Policy (CSP): Specifies allowed sources for web content.

CSP helps guard against cross-site scripting (XSS) attacks. It lets developers define rules for which content sources are legitimate for their web application.

1Content-Security-Policy: default-src 'self'; script-src 'self' example.com; style-src 'self' fonts.googleapis.com; img-src 'self' https://example.com data:;

default-src 'self';

Sets the default source for content that has no more specific directive. Here, 'self' means content like scripts, styles, and images should load from the same origin as the page.

script-src 'self' example.com;

Sets which sources scripts can run from. Here it allows the same origin ('self') and 'example.com'. Scripts from other domains won't run.

style-src 'self' fonts.googleapis.com;

Sets the allowed sources for stylesheets. It permits the same origin ('self') and 'fonts.googleapis.com', so you can use Google Fonts.

img-src 'self' https://example.com data:;

Controls where images can load from. It allows the same origin ('self'), the 'data:' scheme for inline data, and the external domain https://example.com.

You can also configure a policy with the meta element.

1<meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https://*;" />

Quick Recap

1. Request Headers

   • Provide information about the client's preferences
   • Handle authentication and security
   • Manage caching behavior
   • Control content negotiation

2. Response Headers

   • Indicate server status and content type
   • Manage caching and compression
   • Handle connection management
   • Control content delivery

3. Security Headers

   • Enforce HTTPS with HSTS
   • Prevent XSS with CSP
   • Control resource loading
   • Protect against common web vulnerabilities

References

• MDN - HTTP
• MDN - Basics of HTTP
• MDN - Content Security Policy (CSP)