ietf-corpus

rfc-2068

Hypertext Transfer Protocol -- HTTP/1.1

R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee
date1997-01 streamIETF areaapp wghttp statusPROPOSED STANDARD pages162 canonicalhttps://www.rfc-editor.org/rfc/rfc2068 doi10.17487/RFC2068
The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. [STANDARDS-TRACK]

obsoleted by

Extracted elements (30)

design-rationale §1.1

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.

http

design-rationale §3.7.1

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.

http

design-rationale §19.5.1

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

interoperability-note §19.7.1

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.

http, tcp

normative-requirement §3.1 MUST

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.

http

normative-requirement §3.6 MUST

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.

http

normative-requirement §14.23 MUST

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).

http

normative-requirement §8.2 MUST NOT

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

normative-requirement §3.3.1 MUST

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.

http

normative-requirement §4.4 MUST NOT

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.

http

normative-requirement §5.1.2 MUST NOT

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.

http

normative-requirement §5.1.1 MUST

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.

http

normative-requirement §3.7.1 MUST

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.

http

privacy-consideration §15.7

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.

http, privacy

protocol-element §13.2

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.

http

protocol-element §12

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.

http

protocol-element §3.11

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

protocol-element §3.1

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.

http

protocol-element §4.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.

http

protocol-element §8.1

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.

http, tcp

protocol-element §14.36

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.

http

protocol-element §5.1.2

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.

http

protocol-element §14.9

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.

http

protocol-element §14.44

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.

http

registry §3.5

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, registry

security-consideration §15.8

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.

http, security, dns

security-consideration §15.4

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.

http, security

security-consideration §15.3

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.

http, security, privacy

security-consideration §11

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.

http, security

wire-format §3.6

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.

http