Hypertext Transfer Protocol -- HTTP/1.1
obsoleted by
- rfc-2616 — Hypertext Transfer Protocol -- HTTP/1.1
Extracted elements (30)
HTTP/1.1 was introduced because HTTP/1.0 did not adequately address hierarchical proxies, caching, persistent connections, and virtual hosts. The proliferation of incompletely-implemented HTTP/1.0 applications also necessitated a new version number to allow communicating applications to determine each other's true capabilities.
The default charset of ISO-8859-1 for text types was made explicit in HTTP/1.1 because some HTTP/1.0 software incorrectly interpreted a missing charset parameter to mean 'recipient should guess.' HTTP/1.1 mandates a defined default to eliminate this ambiguity.
The Host header was made mandatory in HTTP/1.1 (rather than optional as in HTTP/1.0) to enable virtual hosting—multiple websites sharing a single IP address. Without it, the server cannot determine which virtual host the client is requesting when serving multiple domains.
HTTP/1.1 persistent connections differ from HTTP/1.0 Keep-Alive: connections are persistent by default in HTTP/1.1. To interoperate with HTTP/1.0 proxies that may not support persistent connections, HTTP/1.1 proxies MUST NOT establish persistent connections with HTTP/1.0 clients unless Keep-Alive is explicitly negotiated.
A proxy or gateway MUST never forward a message with a version indicator greater than its actual version. If a higher-version request is received, the proxy MUST either downgrade the request version, respond with an error, or switch to tunnel behavior.
All HTTP/1.1 applications MUST be able to receive and decode the 'chunked' transfer coding. A server MUST NOT send transfer-codings to an HTTP/1.0 client. A server receiving an unknown transfer-coding SHOULD return 501 and close the connection.
An HTTP/1.1 client MUST send a Host header field in all HTTP/1.1 request messages. If the Request-URI is not absolute and no Host header is present, or the determined host is not valid, the server MUST respond with 400 (Bad Request).
An HTTP/1.1 client that sends a request with a body and includes 'Expect: 100-continue' MUST NOT send the request body until it receives a 100 (Continue) response. This avoids sending a large body to a server that would reject the request.
HTTP/1.1 clients and servers that parse date values MUST accept all three historical formats (RFC 1123, RFC 850, ANSI C asctime) for HTTP/1.0 compatibility, but MUST only generate the RFC 1123 format for HTTP-date fields.
Messages MUST NOT include both a Content-Length header field and the 'chunked' transfer coding. If both are received, Content-Length MUST be ignored. HTTP/1.1 requests with a message body MUST include a valid Content-Length unless the server is known to be HTTP/1.1 compliant.
Proxies MUST NOT rewrite the abs_path part of a Request-URI in any way, except to replace a null abs_path with '*', regardless of the proxy's internal implementation. This prevents proxies from changing the meaning of a request when the origin server uses non-reserved characters for reserved purposes.
The methods GET and HEAD MUST be supported by all general-purpose servers. Servers SHOULD return 405 (Method Not Allowed) if a known method is not allowed for the resource, and 501 (Not Implemented) if the method is unrecognized.
When no explicit charset parameter is provided, media subtypes of the 'text' type received via HTTP default to ISO-8859-1. HTTP/1.1 recipients MUST respect the charset label provided by the sender; user agents that 'guess' a charset MUST use the content-type field's value if supported.
Accept-type headers (Accept, Accept-Charset, Accept-Encoding, Accept-Language) reveal information about the user's software configuration and preferences that may be used for fingerprinting or tracking. Sending broad accept headers can inadvertently expose user identity.
Cache freshness is determined by computing the response's age (time since the origin server sent it) and comparing it against freshness lifetime derived from max-age, Expires, or heuristic estimation. A response is 'fresh' when age < freshness_lifetime; otherwise it is 'stale' and requires revalidation.
Content negotiation uses Accept, Accept-Charset, Accept-Encoding, and Accept-Language request headers with quality values (0.0–1.0) for server-driven negotiation. The Vary response header lists the request fields that were used to select the response, enabling correct caching.
Entity tags are opaque quoted strings used as cache validators, optionally prefixed by 'W/' to indicate weakness. A strong entity tag requires byte-for-byte equivalence; a weak tag ('W/"etag"') indicates semantic equivalence and may only be used for weak comparison.
HTTP-Version is encoded as 'HTTP' '/' 1*DIGIT '.' 1*DIGIT. Major and minor numbers MUST be treated as separate integers; leading zeros MUST be ignored by recipients and MUST NOT be sent. HTTP/2.13 is higher than HTTP/2.4.
Message length is determined in order of precedence: (1) responses that MUST NOT include a body terminate at the first empty line; (2) chunked Transfer-Encoding defines length; (3) Content-Length value; (4) multipart/byteranges self-delimiting; (5) server closes connection.
Persistent connections (HTTP/1.1 default) allow multiple request/response exchanges over a single TCP connection. The Connection header controls per-connection options; 'Connection: close' signals that the connection will be closed after the response.
Range requests allow a client to retrieve a sub-range of a response entity using the Range header with byte-range specifiers (e.g., bytes=0-499). A 206 Partial Content response includes a Content-Range header; multiple ranges produce a multipart/byteranges body.
Request-URI takes three forms: '*' for server-wide requests (e.g., OPTIONS), absoluteURI for requests to proxies, and abs_path for direct origin server requests. All HTTP/1.1 servers MUST accept absoluteURI in requests even though clients only generate it for proxies.
The Cache-Control header provides directives for both requests and responses, including no-cache, no-store, max-age, s-maxage, must-revalidate, proxy-revalidate, public, private, and no-transform, giving fine-grained control over caching behavior.
The Via header records the protocol version and host of each proxy or gateway through which a message passes. Proxies MUST add a Via field to both forwarded requests and responses, and MAY combine multiple entries for the same host into one.
IANA acts as registry for content-coding value tokens used in Accept-Encoding and Content-Encoding. Initial values are 'gzip' (LZ77 + CRC32), 'compress' (LZW), and 'deflate' (zlib/RFC 1950 + deflate/RFC 1951). New tokens must be publicly documented for independent implementation.
HTTP clients using DNS to resolve server names are vulnerable to DNS spoofing, where a falsified DNS response redirects requests to a malicious server. Once connected, a client may send sensitive data (including credentials) to the attacker.
Sensitive information such as authentication credentials and personal data SHOULD only be transferred over secure channels. HTTP by default provides no encryption or authentication of the transport, and proxies on the path can observe all data.
Server log information including Referer and From headers can reveal sensitive details about users' browsing habits and email addresses. This information MUST be treated with discretion; users should be made aware of what information is logged and how it may be used.
The Basic authentication scheme encodes credentials as base64-encoded plaintext, providing no confidentiality protection. HTTP/1.1 also defines Digest authentication as a stronger alternative; servers SHOULD offer stronger schemes when available.
Chunked-Body consists of zero or more chunks (hex chunk-size, optional chunk-ext, CRLF, chunk-data, CRLF), terminated by a zero-sized chunk followed by an optional footer of entity-header fields and a final CRLF, enabling transfer of dynamically-generated content.