HTTP Headers | Teleinf Edu

HTTP fields and message context

An HTTP message carries a request or response together with named metadata fields. These fields describe the target, representation, authentication, caching, or processing rules. In the web protocol, this metadata is conveyed through .

In HTTP/1.1, fields follow the request line or status line and use a case-insensitive field name followed by a colon and field value. HTTP/2 and HTTP/3 encode fields in a binary representation, while the shared semantics remain. For example, Content-Type: text/html identifies an HTML media type. Other fields control caching, authentication, security policy, content coding, and cookie state.

HTTP field groupings

The labels below are a teaching framework, not a four-part classification used by every HTTP version. Current HTTP semantics define fields by their meaning and message context, while HTTP/2 and HTTP/3 add pseudo-fields and prohibit connection-specific fields such as Connection.

General Headers: These fields can occur in requests and responses and describe the message or its processing. Date records the message origination time. Connection carries hop-by-hop options in HTTP/1.1; HTTP/2 and HTTP/3 prohibit that field.
Request Headers: These fields describe the request context or client preferences. A browser can send User-Agent, Accept-Language, and Authorization. The protocol does not require every request field to come from a browser or to be present in every request.
Response Headers: These fields describe a response or instruct the client how to process it. Examples include Server, Location for redirection, and Set-Cookie for storing cookie state. Their use is defined by the field semantics rather than by the sender alone.
Representation Headers (formerly Entity Headers): These fields describe a representation or its coded form. They can appear in requests and responses. Examples include Content-Type and Content-Encoding. Content-Length indicates the representation data length and can delimit HTTP/1.1 message framing.

A field can appear in more than one message context when its definition allows it, and an extension can define a new field name. Field names are case-insensitive, while field values follow the syntax and comparison rules of each field. This distinction matters when an intermediary combines, forwards, or removes fields during a protocol-version conversion.

Representation fields

Representation fields describe the data format, length, and content codings. They let a recipient process the representation according to declared metadata instead of guessing.

Content-Type

This field identifies the media type of the representation in the message content. A browser can use it to select an HTML parser, a stylesheet processor, a script handler, or an image decoder.

The value is a , often followed by media-type parameters.

Common MIME types

text/html: For standard webpages.
text/css: For stylesheets.
text/javascript: For JavaScript code.
application/json: For data in JSON format, common in APIs.
image/jpeg, image/png: For images.
multipart/form-data: For form submissions that include file uploads.

Media-type parameters

Parameters add information to a media type. For example, charset identifies the character encoding, such as $UTF-8$ .

Content-Type: text/html; charset=UTF-8

Content-Length

This field gives the representation data length as a non-negative decimal number of octets. In HTTP/1.1 it can delimit a message body when transfer coding is not used. Other versions and message cases can use their own framing rules, so a recipient does not always wait for the connection to close.

Content-Length: 1548

Content-Encoding

This field lists the content codings applied to the representation, such as compression. The recipient removes those codings before processing the media type identified by Content-Type. The field describes representation coding, not the HTTP/1.1 transfer framing.

Common Encodings:

gzip: A widely supported and effective compression format.
deflate: The HTTP deflate content coding.
br: Brotli content coding, developed by Google and often more efficient than gzip.

Content-Encoding: gzip

Content metadata and transfer framing answer different questions. Content-Type describes the media type, and Content-Encoding describes codings applied to that representation. HTTP/1.1 uses message-framing rules such as Content-Length or transfer coding, while HTTP/2 and HTTP/3 carry the content in protocol frames. An intermediary must keep the declared length consistent with the received framing.

Request fields for context and control

Request fields provide target information, preferences, and credentials. They support routing, content negotiation, and authentication when the field semantics and transport security are appropriate.

Host

In HTTP/1.1, a request must contain a Host field. It carries the host and optional port from the target URI, allowing . In HTTP/2 and HTTP/3, the :authority pseudo-field can carry the same authority information. One server address can therefore serve many domain names when the server uses that authority to select a site.

Host: www.example.com

Accept-* Headers and Content Negotiation

Content negotiation lets a client list acceptable representations, and lets a server select one representation of a resource. The request uses fields such as Accept-*.

Accept: Tells the server which media types (MIME types) the client can understand. For example, a browser might indicate it can handle HTML, XML, and images.
Accept-Language: Informs the server about the user's preferred language(s). This allows a server to respond with a page in English, French, or Spanish based on the user's browser settings.
Accept-Encoding: Informs the server which compression algorithms the client supports.

A client can attach a quality value from 0 to 1 to many list members. A higher value expresses a stronger preference, while 0 means that the member is not acceptable. For instance, Accept-Language: fr-CH, fr;q=0.9, en;q=0.8, de;q=0.7, *;q=0.5 expresses a preference for Swiss French, then French, English, German, and other languages.

Authorization

This field carries credentials for an authentication scheme selected by the server and client. Two common schemes are:

Basic: This scheme sends a username and password encoded with Base64. Base64 provides no confidentiality, so the credentials require HTTPS or equivalent transport security.
```
Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l
```
Bearer: This scheme carries an access token, commonly issued by . The token can be opaque or structured, such as a JSON Web Token, and the resource server validates it according to the issuing system's rules. Bearer tokens require transport confidentiality.
```
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
```

Cache-Control and validators

HTTP caches store responses and can reuse them for later equivalent requests. Cache fields define freshness, validation, and whether a shared cache may reuse a response. Reuse reduces repeated transfer of unchanged representations.

Cache-Control

Cache-Control carries request and response directives. Response directives describe how a cache stores and reuses a response:

public: The response may be stored by any cache, including shared proxies.
private: The response is intended for a single user and must not be stored by a shared cache. The user's private browser cache can still store it.
no-store: The cache must not store the response.
no-cache: A stored response must be validated before reuse. The directive does not by itself prohibit storage.
max-age= $seconds$ : Sets the response freshness lifetime in seconds. A fresh response can be reused without contacting the origin.

# Cache this image in all caches for one year
Cache-Control: public, max-age=31536000

# Cache user-specific data in the browser for one hour
Cache-Control: private, max-age=3600

# Always check with the server before using the cached HTML
Cache-Control: no-cache

ETag and If-None-Match (Validation)

When a response becomes stale, its representation may still match the current resource. HTTP validators allow a cache to check that condition without transferring the full representation.

The server includes an ETag field in its response. The name means entity tag; an ETag is an opaque validator for a selected representation and can be strong or weak.
When the browser needs to re-validate the stale resource, it makes a conditional GET request and includes the ETag value in an If-None-Match request header.
The server compares the validator with the current representation. For a matching conditional GET, it returns 304 Not Modified without the representation content, allowing the cache to reuse its stored response after updating its metadata.

Cache behavior also depends on request context. A response selected through content negotiation can use Varyto tell caches which request fields affect the representation. Responses associated with authorization or private session data need restrictions that prevent a shared cache from serving one user's content to another. These field semantics link message framing with representation, authentication, and privacy. A cache must parse these directives before it decides whether a stored response can satisfy a request.