HTTP/1.1 introduced strict version negotiation requirements (stricter than HTTP/1.0) because the proliferation of incompletely-implemented HTTP/1.0 applications made it impossible for two communicating applications to determine each other's true capabilities.

http

The chunked transfer-coding was introduced to solve the HTTP/1.0 problem of needing to know content-length before sending a body, which prevented dynamically generated content from using persistent connections. It also enables the server to include trailer metadata after the body.

http

A server MUST NOT send transfer-codings to an HTTP/1.0 client. For HTTP/1.0 compatibility, applications SHOULD treat 'x-gzip' and 'x-compress' as equivalent to 'gzip' and 'compress' respectively. HTTP/1.1 requires more stringent compliance than HTTP/1.0 to ensure reliable feature implementation.

http

A proxy MUST NOT change the order of header field values with the same field-name when forwarding a message. Multiple header fields with the same field-name MAY be present only if the entire field-value is defined as a comma-separated list.

http

A proxy or gateway MUST NOT send a message with a version indicator greater than its actual version. If a higher-version request is received, it MUST downgrade the request, respond with an error, or switch to tunnel behavior. Caching proxies MUST NOT upgrade the request version.

http

All HTTP/1.1 applications MUST be able to receive and decode the 'chunked' transfer-coding and MUST ignore chunk-extension extensions they do not understand. A server MUST NOT send transfer-codings to an HTTP/1.0 client.

http

All responses to HEAD requests MUST NOT include a message-body. All 1xx (informational), 204 (No Content), and 304 (Not Modified) responses MUST NOT include a message-body, even if entity-header fields are present.

http

An HTTP/1.1 client MUST send a Host header field in all HTTP/1.1 request messages. If the requested URI does not include an Internet host name, the Host header field value MUST be sent as an empty string.

http

HTTP/1.1 recipients MUST respect the charset label provided by the sender; user agents that can guess a charset MUST use the charset from the content-type field if supported, rather than the recipient's preference, when initially displaying a document.

http

HTTP/1.1 requests containing a message-body MUST include a valid Content-Length unless the server is known to be HTTP/1.1 compliant. If the server cannot determine message length it SHOULD return 400; if it requires Content-Length it SHOULD return 411.

http

Transfer-length is determined in precedence order: (1) response type mandating no body; (2) non-identity Transfer-Encoding implying chunked; (3) Content-Length decimal value; (4) multipart/byteranges self-delimiting; (5) connection close. If both Transfer-Encoding and Content-Length are present, Content-Length MUST be ignored.

http

URI host name comparisons MUST be case-insensitive and scheme name comparisons MUST be case-insensitive. An empty abs_path is equivalent to '/' and an absent port is equivalent to the default port for the scheme.

http

Whenever a transfer-coding is applied to a message-body, the set MUST include 'chunked' unless the message is terminated by closing the connection. 'chunked' MUST be the last transfer-coding applied and MUST NOT be applied more than once to a message-body.

http

Accept headers (Accept-Language, Accept-Charset, Accept-Encoding) expose user preferences and can be used to fingerprint users across sites. Revealing language preferences may disclose nationality or locale. User agents SHOULD allow users to disable sending these headers.

http, privacy

Cache-Control header provides directives for caching including: no-cache, no-store, max-age, s-maxage, must-revalidate, proxy-revalidate, public, private, no-transform. Cache freshness is determined by explicit expiration (Expires/max-age) or heuristic expiration based on Last-Modified.

http

Entity tags are opaque quoted strings used as cache validators, optionally prefixed with 'W/' for weak comparison. A strong entity tag MAY be shared by two entities only if equivalent by octet equality; a weak entity tag requires only semantic equivalence. Entity tags MUST be unique across all versions of a resource.

http

HTTP/1.1 defaults to persistent connections, allowing multiple request/response exchanges on a single TCP connection. Either party may signal closure with 'Connection: close'. HTTP/1.0 compatibility requires treating the absence of Connection header as non-persistent.

http, tcp

HTTP defines eight methods: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, and CONNECT. GET and HEAD are 'safe' (no side effects). GET, HEAD, PUT, DELETE, OPTIONS, and TRACE are idempotent (multiple identical requests have the same effect as a single request).

http

The 100 (Continue) status code allows a client with a large request body to first send just the headers (with Expect: 100-continue), wait for server confirmation, then send the body. This avoids sending a large body to a server that will reject the request.

http

The Vary response header specifies the set of request-header fields that fully determines which cached response is acceptable for a request. Caches MUST use the Vary value to select or revalidate a cached response; 'Vary: *' makes a response uncacheable by shared caches.

http

IANA acts as registry for content-coding value tokens. Initially registered: 'gzip' (RFC 1952 LZ77+CRC32), 'compress' (LZW), 'deflate' (RFC 1950 zlib + RFC 1951 deflate), and 'identity' (no transformation). New tokens SHOULD be publicly specified to enable independent implementation.

http, registry

IANA acts as registry for transfer-coding value tokens. Initially registered: 'chunked', 'identity', 'gzip', 'compress', and 'deflate'. New transfer-coding tokens SHOULD be registered in the same manner as content-coding tokens.

http, registry

Authentication credentials sent over persistent connections or stored in caches risk exposure to unauthorized parties. Shared caches MUST NOT return responses with Authorization headers unless explicitly permitted by Cache-Control (must-revalidate, public, or s-maxage).

http, security

DNS spoofing is a risk for HTTP clients and caching proxies: a hostile DNS server can cause misdirected requests. HTTP security relies on the security of DNS; clients and proxies that cache DNS lookups should apply short TTLs and re-verify host identity when handling sensitive operations.

http, security, dns

Server log information is sensitive: logs contain request URIs, IP addresses, and potentially personal information. Operators MUST protect logs and consider privacy when designing log retention. Clients SHOULD NOT include sensitive information in query strings since those appear in logs and Referer headers.

http, security, privacy

An HTTP message consists of a start-line (Request-Line or Status-Line), zero or more 'field-name: field-value' header lines each terminated by CRLF, an empty CRLF line ending the headers, and an optional message-body. CRLF is the end-of-line marker for all protocol elements except the entity-body.

http

Chunked transfer encoding formats the body as: *(chunk-size [chunk-extension] CRLF chunk-data CRLF) last-chunk trailer CRLF, where chunk-size is a hex string indicating the number of octets in chunk-data and the last-chunk has a zero size. An optional trailer of entity-header fields may follow.

http

HTTP-date may be one of three formats: RFC 1123 ('Sun, 06 Nov 1994 08:49:37 GMT'), RFC 850 ('Sunday, 06-Nov-94 08:49:37 GMT'), or ANSI C asctime ('Sun Nov 6 08:49:37 1994'). All three MUST be accepted; only RFC 1123 MUST be generated. All dates MUST be in GMT.

http

The HTTP-Version field has the form '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