Generated by DeepSeek V3.2| RFC 2616 | |
|---|---|
| Title | Hypertext Transfer Protocol -- HTTP/1.1 |
| Number | 2616 |
| Author | Roy Fielding, Jim Gettys, Jeffrey Mogul, Larry Masinter, Paul Leach, Tim Berners-Lee |
| Pubdate | June 1999 |
| Status | Obsolete |
| Series | RFC |
| Updates | RFC 2068 |
| Obsoletes | RFC 2068 |
| Obsoleted by | RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235 |
RFC 2616 was the definitive specification for version 1.1 of the Hypertext Transfer Protocol, the foundational protocol of the World Wide Web. Published in June 1999 by the Internet Engineering Task Force, it formally obsoleted the earlier RFC 2068 and was authored by key figures including Tim Berners-Lee and Roy Fielding. The document meticulously defined the syntax, semantics, and core components for communication between clients, such as web browsers, and servers, enabling the modern web's functionality for over a decade.
RFC 2616 was developed to address limitations and ambiguities present in the earlier HTTP/1.0 protocol, standardizing features essential for performance and reliability on the growing Internet. Its primary purpose was to define a stateless, application-level protocol for distributed, collaborative, hypermedia information systems, which form the architecture of the World Wide Web. The specification aimed to improve efficiency over HTTP/1.0 by mandating support for persistent connections, introducing chunked transfer encoding, and providing finer-grained cache controls. This work was a product of the HTTP Working Group within the Internet Engineering Task Force, building upon the foundational concepts of the original World Wide Web Consortium proposals.
The protocol operates as a request-response exchange, typically over a Transmission Control Protocol connection, using a standardized message format of a start-line, headers, and an optional message-body. It introduced critical performance features like persistent connections, allowing multiple requests and responses over a single TCP session to reduce latency. The specification also detailed mandatory support for the `Host` header field, which was crucial for the rise of virtual hosting on shared IP addresses. Other key technical elements included content negotiation mechanisms, byte-range requests for partial content retrieval, and comprehensive caching semantics to control the behavior of intermediary proxy servers and client caches.
RFC 2616 defined a set of request methods indicating the desired action to be performed on an identified resource. The primary method, `GET`, requests a representation of a specified resource, while `HEAD` is identical but transfers only the status line and header section. The `POST` method submits an entity to the specified resource, often causing a change in state or side effects, and was central to form submissions on the web. Other important methods included `PUT` for uploading a representation of a resource, `DELETE` for removing it, `OPTIONS` for describing communication options, and `TRACE` for diagnostic message loops, with safety and idempotency properties formally described.
Header fields function as the primary mechanism for conveying metadata about the request or response, or about the object sent in the message body. The specification categorized headers into general-headers, request-headers, response-headers, and entity-headers, each with defined syntax and semantics. Critical headers included `Content-Type`, indicating the media type of the entity-body; `Cache-Control`, providing directives for caching mechanisms; and `User-Agent`, containing information about the originating client software like Mozilla Firefox or Microsoft Internet Explorer. The syntax for dates followed a fixed format defined in RFC 1123, and the protocol used a character set based on US-ASCII.
The status code is a three-digit integer within a response's status-line, giving the result of the attempt to understand and satisfy the request. Codes are grouped into five classes: informational (`1xx`), success (`2xx`), redirection (`3xx`), client error (`4xx`), and server error (`5xx`). Definitive codes included `200 OK` for a successful request, `404 Not Found` when the server could not locate the resource, and `500 Internal Server Error` for an unexpected server condition. Redirection codes like `301 Moved Permanently` and `302 Found` were essential for URL management, while authentication challenges used `401 Unauthorized`.
RFC 2616 was deeply interconnected with numerous other Internet Standards. It relied heavily on Uniform Resource Identifier syntax defined in RFC 2396 and used Internet media types registered with the Internet Assigned Numbers Authority. The specification referenced RFC 2109 for state management using HTTP cookies and interacted with security protocols like Transport Layer Security. It also informed the development of related standards for web services and APIs, and its semantics influenced the design of the Representational State Transfer architectural style.
Due to accumulated errata, ambiguities, and implementation complexities, RFC 2616 was officially obsoleted in June 2014 by a new series of documents from the HTTP Working Group. This series, comprising RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, and RFC 7235, refined and clarified the protocol specification by splitting it into more manageable, focused parts. The newer documents collectively provided a more precise and implementable standard, though RFC 2616 remained historically significant as the long-standing blueprint for HTTP/1.1 that powered the expansion of the World Wide Web through the 2000s. Category:Internet standards Category:Hypertext Transfer Protocol Category:Request for Comments