Understanding HTTP Headers

HTTP headers are essential components of the Hypertext Transfer Protocol (HTTP), used for communication between web browsers and servers.

When you opened this blog post, your browser sent a couple of HTTP requests to GET the HTML content to display in your browser, and it received an HTTP response for each one of them. HTTP headers hold information about the request or response being sent and provide additional instructions for the server or browser.

Example

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

GET /blog/http-headers/ HTTP/1.1
Accept: 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
Accept-Encoding:  gzip, deflate, br
Accept-Language: en-US,en;q=0.9,ar;q=0.8,ru;q=0.7
Cache-Control: no-cache
Connection: keep-alive
Host: mohammadshehadeh.com
Pragma: no-cache
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Upgrade-Insecure-Requests: 1
User-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 a response like this:

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

Let's break down and explain each header

Request headers#

Request Line
```
GET /blog/http-headers/ HTTP/1.1
```
This is the request line, indicating that the client is making a GET request for the resource located at /blog/http-headers/ using HTTP version 1.1.
Accept
```
Accept: 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
```
Specifies the media types that the client can understand and is willing to accept. It includes a list of preferred content types with associated quality values (q-values).
Accept-Encoding
```
Accept-Encoding: gzip, deflate, br
```
Informs the server about the encodings that the client supports for the response. Common values include gzip, deflate, and br (Brotli).
Accept-Language
```
Accept-Language: en-US,en;q=0.9,ar;q=0.8,ru;q=0.7
```
Indicates the natural language and locale that the client prefers.
Cache-Control
```
Cache-Control: no-cache
```
Directs how caching should be performed, and in this case, it indicates "no-cache" suggesting that the client prefers a fresh response from the server rather than a cached one.
Connection
```
Connection: keep-alive
```
Specifies whether the connection should be kept alive (keep-alive) or closed after the current request/response is completed.
Host
```
Host: mohammadshehadeh.com
```
Specifies the domain name and port number of the server the client is trying to reach. If no port is included, the default port for the service requested is implied (e.g., 443 for an HTTPS URL, and 80 for an HTTP URL).
Pragma
```
Pragma: no-cache
```
Used for backward compatibility with HTTP/1.0. In this case, it indicates no-cache. This header serves for backward compatibility with the HTTP/1.0 caches that do not have a Cache-Control HTTP/1.1 header.
Upgrade-Insecure-Requests
```
Upgrade-Insecure-Requests: 1
```
Suggests that the client prefers to use a secure connection (HTTPS) if the server supports it.
Sec-Fetch Headers
```
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
```
- Sec-Fetch-Dest: Describes the destination of the request. In this case, it's set to "empty."
- Sec-Fetch-Mode: Describes how the request was initiated. Here, it's set to "navigate," indicating navigation to a new browsing context.
- Sec-Fetch-Site: Informs the server about the site from which the request originates. In this case, it's set to "same-origin."
Origin

Indicates the origin (scheme, hostname, and port) that initiated the request <scheme>://<hostname>:<port>
User-Agent
```
User-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. It provides information about the client's software, operating system, and version.
Authorization
```
Authorization: Bearer "token"
```
Used to send credentials for authentication purposes. Commonly, it contains encrypted information.
Cookie
```
Cookie: name=value; sessionID=abc123
```
Sends previously-stored cookies back to the server.
Access-Control-Request-Method
```
Access-Control-Request-Method: POST
```
Used by browsers with a preflight request, to let the server know which HTTP method will be used when the actual request is made.
Access-Control-Request-Headers
```
Access-Control-Request-Headers: Content-Type, x-requested-with
```
Used by browsers with a preflight request, to let the server know which HTTP headers will be used when the actual request is made. Access-Control-Allow-Headers header from the server side will answer this browser-side header.

Response headers#

Status Line
```
HTTP/1.1: 200 OK
```
Indicates that the server successfully processed the request
Vary
```
Vary: RSC, Next-Router-State-Tree, Next-Router-Prefetch, Next-Url, Accept-Encoding
```
Describes the parts of the request message aside from the method and URL that influenced the content of the response it occurs in. Most often, this is used to create a cache key when content negotiation is in use
Date
```
Date: Sun, 11 Feb 2024 19:59:53 GMT
```
Represents the date and time when the server sent the response. It helps in determining the freshness of the response.
Keep-Alive
```
Keep-Alive: timeout=5
```
Provides information about the keep-alive timeout, indicating how long the connection should be kept open for potential future requests.
Transfer-Encoding
```
Transfer-Encoding: chunked
```
Indicates that the response is using chunked transfer encoding, where the response is sent 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.

usually, users may initially communicate with HTTP version of the site before being redirected to HTTPS version; The strict Transport Security header informs the browser that it should never load a site using HTTP and should automatically convert all attempts to access the site using HTTP to HTTPS requests instead.

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

CSP helps guard against cross-site scripting attacks Cross-site scripting (XSS), It allows web developers to define a set of rules specifying which sources of content are considered legitimate for their web application.

Content-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';

The default-src directive sets the default source for content that doesn't have a more specific directive. In this case, 'self' means that content (e.g., scripts, styles, images) should primarily be loaded from the same origin as the web page itself.

script-src 'self' example.com;

The script-src directive specifies the sources from which scripts can be executed. Here, it allows scripts from the same origin ('self') and from the domain 'example.com'. Scripts from other domains won't be executed.

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

The style-src directive defines the allowed sources for stylesheets. It permits styles from the same origin ('self') and from 'fonts.googleapis.com', allowing the use of fonts from Google Fonts.

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

The img-src directive controls the allowed sources for loading images. It allows images from the same origin ('self') and from the 'data:' scheme, which is used for inline data and from specified external domain https://example.com.

the meta element can be used to configure a policy

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

Conclusion#

HTTP requests are like messages sent between web browsers and servers to retrieve resources like web pages. Requests are started by clients, and they include different headers that provide information about the request, the client's preferences, and authentication details

Request headers#

Response headers#

Security Headers#

Conclusion#

References#

Let’s work together