HTTP Parameters

HTTP - Protocol Parameters

This chapter outlines key parameters and their syntax used in HTTP communication. Understanding these is crucial for constructing valid HTTP requests and responses, and for developing HTTP clients or servers. These parameters form the building blocks of HTTP messages, which are detailed in subsequent chapters.

HTTP Version

HTTP uses a Major.Minor numbering scheme for protocol versions. The version is indicated in the first line of an HTTP message (request line or status line).

Syntax: `HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT`

Examples:

HTTP/1.1
HTTP/2
HTTP/3

Note: While HTTP/2 and HTTP/3 have different wire formats (binary framing), they largely retain the semantics of HTTP/1.1, including methods, status codes, and headers. HTTP/2 requests still effectively start with HTTP/2 in their internal representation, and HTTP/3 refers to its semantics as HTTP/3.

Uniform Resource Identifiers (URI)

A Uniform Resource Identifier (URI) is a compact string of characters used to identify or name a resource. In the context of HTTP, URLs (Uniform Resource Locators) are the most common form of URI.

General Syntax for HTTP(S) URLs: `URI = scheme ":" "//" host [ ":" port ] [ abs_path [ "?" query ]] [ "#" fragment ]`

• scheme: http or https (preferred for security).
• host: The domain name or IP address of the server.
• port: Optional. Defaults to 80 for http and 443 for https.
• abs_path: The path to the resource on the server. If empty, defaults to ”/”.
• query: Optional. A string of key-value pairs, typically starting with ’?’ and separated by ’&’.
• fragment: Optional. Refers to a specific part within a resource, processed client-side.

Characters not in the unreserved set or with special meaning must be percent-encoded.

Example:

https://www.example.com/path/to/resource?name=test&lang=en#section1

Equivalent forms (case-insensitivity in scheme and host, default port, path normalization):
https://EXAMPLE.COM:443/path/to/resource?name=test&lang=en#section1

Date/Time Formats

All HTTP date/time stamps MUST be represented in Greenwich Mean Time (GMT), now known as Coordinated Universal Time (UTC). The preferred format is defined in RFC 7231 (which updates RFC 2616, referencing RFC 1123, which updated RFC 822).

Preferred format: `IMF-fixdate = day-name "," SP date1 SP time-of-day SP "GMT"`
Example: `Sun, 06 Nov 1994 08:49:37 GMT`

While older RFCs (RFC 850, ANSI C’s asctime() format) were sometimes supported for backward compatibility, modern implementations should strictly use and expect the IMF-fixdate format (e.g., Date, Expires, Last-Modified headers).

Character Sets

Character sets (encodings) specify how characters are represented as bytes. For HTTP, UTF-8 is the overwhelmingly dominant and recommended character set for content.

The charset parameter of the Content-Type header indicates the character encoding of the entity body. The Accept-Charset request header can be used by clients to indicate which character sets they can understand, though it’s less common now due to UTF-8’s prevalence.

Example:

Content-Type: text/html; charset=utf-8
Content-Type: application/json; charset=utf-8

// Old, less common example:
// Accept-Charset: utf-8, iso-8859-1;q=0.5

Defaulting to US-ASCII or ISO-8859-1 is a legacy behavior; modern applications should explicitly use and expect UTF-8.

Content Encodings

Content encodings indicate transformations (usually compression) applied to the entity-body before transmission. This is distinct from character encoding.

The Content-Encoding header in a response specifies the encodings applied. The Accept-Encoding header in a request tells the server which content encodings the client supports. Common values include gzip, deflate, and br (Brotli, offering better compression). identity means no encoding.

Example:

// Client request:
Accept-Encoding: gzip, deflate, br

// Server response:
Content-Encoding: br

The compress (LZW) encoding is largely obsolete.

Media Types (MIME Types)

HTTP uses Media Types (also known as MIME types) in the Content-Type (for responses and request bodies) and Accept (for requests) headers to specify the nature and format of the data.

Syntax: `media-type = type "/" subtype *(";" parameter)`
Parameters are typically key-value pairs, like `charset=utf-8`.

Type, subtype, and parameter names are case-insensitive. Parameter values may be case-sensitive.

Examples:

Content-Type: text/html; charset=utf-8
Content-Type: application/json
Content-Type: image/jpeg
Content-Type: application/xml
Content-Type: multipart/form-data; boundary=something

// Client request:
Accept: application/json, text/plain, */*

Media types are registered with IANA (Internet Assigned Numbers Authority).

Language Tags

HTTP uses language tags (defined by BCP 47, which incorporates RFC 5646 and others) in the Content-Language (response) and Accept-Language (request) headers to indicate the language(s) of the content or preferred by the user.

Syntax: `language-tag = primary-tag *("-" subtag)`
Tags are case-insensitive. White space is not allowed within a tag.

Examples:

Content-Language: en-US
Accept-Language: fr-CH, fr;q=0.9, en;q=0.8, de;q=0.7, *;q=0.5

Common tags include:
'en' (English)
'en-US' (English, as used in the United States)
'es-419' (Spanish, appropriate for Latin America and Caribbean region)
'zh-Hant' (Chinese written in traditional script)

The q value (quality value) in Accept-Language indicates user preference (0.0 to 1.0).