Network Working GroupR. Fielding
Internet-DraftDay Software
Obsoletes: 2616 (if approved)J. Gettys
Intended status: Standards TrackJ. Mogul
Expires: April 25, 2007HP
H. Frystyk
L. Masinter
Adobe Systems
P. Leach
T. Berners-Lee
Y. Lafon, Editor
J. Reschke, Editor
October 22, 2006

Hypertext Transfer Protocol -- HTTP/1.1

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress”.

The list of current Internet-Drafts can be accessed at

The list of Internet-Draft Shadow Directories can be accessed at

This Internet-Draft will expire on April 25, 2007.

Copyright Notice

Copyright © The Internet Society (2006). All Rights Reserved.


The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers [47]. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred.

HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1", and is an update to RFC2616.

Editorial Note (To be removed by RFC Editor before publication)

Distribution of this document is unlimited. Please send comments to the Hypertext Transfer Protocol (HTTP) mailing list at, which may be joined by sending a message with subject "subscribe" to Discussions of the HTTP working group are archived at <>. XML versions, latest edits and the issues list for this document are available from <>.

The purpose of this document is to revise RFC2616 ([50]), doing only minimal corrections. For now, it is not planned to advance the standards level of HTTP, thus - if published - the specification will still be a "Proposed Standard" (see [46]).

The current plan is to incorporate known errata, and to update the specification text according to the current IETF publication guidelines. In particular:

This document is based on a variant of the original RFC2616 specification formatted using Marshall T. Rose's "xml2rfc" tool (see <>) and therefore deviates from the original text in word wrapping, page breaks, list formatting, reference formatting, whitespace usage and appendix numbering. Otherwise, it is supposed to contain an accurate copy of the original specification text. See <> for a comparison between both documents, as generated by "rfcdiff" (<>).

 I  rfc2616bis   (type: edit, status: open)
julian.reschke@greenbytes.de2006-10-10 Umbrella issue for changes with respect to the revision process itself.
Associated changes in this document: <#rfc.change.rfc2616bis.1>, <#rfc.change.rfc2616bis.2>, 16.1, 16.1, 16.2, F.
 I  rfc2606-compliance   (type: edit, status: closed)
julian.reschke@greenbytes.de2006-10-19 Make sure that domain names in examples use names reserved for that purpose (see RFC2606).
Resolution: Done.
Associated changes in this document: 5.1.2, 5.1.2, 5.1.2, 14.23, 14.23, 14.30, 14.36, 14.36.
 I  unneeded_references   (type: edit, status: open)
julian.reschke@greenbytes.de2006-10-19 The reference entries for RFC1866, RFC2069 and RFC2026 are unused. Remove them?
 I  edit   (type: edit, status: open)
julian.reschke@greenbytes.de2006-10-08 Umbrella issue for editorial fixes/enhancements.
Associated changes in this document: <#rfc.change.edit.1>, 1.3, 5.1.2, 5.1.2, 5.1.2, 16.1, G, G.2.
 I  editor-notes   (type: edit, status: closed)
fielding@kiwi.ics.uci.edu1999-08-03 See
2006-10-14Resolution: Not applicable. New References section is generated by xml2rfc.

1. Introduction

1.1. Purpose

The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World-Wide Web global information initiative since 1990. The first version of HTTP, referred to as HTTP/0.9, was a simple protocol for raw data transfer across the Internet. HTTP/1.0, as defined by RFC 1945 [6], improved the protocol by allowing messages to be in the format of MIME-like messages, containing metainformation about the data transferred and modifiers on the request/response semantics. However, HTTP/1.0 does not sufficiently take into consideration the effects of hierarchical proxies, caching, the need for persistent connections, or virtual hosts. In addition, the proliferation of incompletely-implemented applications calling themselves "HTTP/1.0" has necessitated a protocol version change in order for two communicating applications to determine each other's true capabilities.

This specification defines the protocol referred to as "HTTP/1.1". This protocol includes more stringent requirements than HTTP/1.0 in order to ensure reliable implementation of its features.

Practical information systems require more functionality than simple retrieval, including search, front-end update, and annotation. HTTP allows an open-ended set of methods and headers that indicate the purpose of a request [47]. It builds on the discipline of reference provided by the Uniform Resource Identifier (URI) [3], as a location (URL) [4] or name (URN) [20], for indicating the resource to which a method is to be applied. Messages are passed in a format similar to that used by Internet mail [9] as defined by the Multipurpose Internet Mail Extensions (MIME) [7].

HTTP is also used as a generic protocol for communication between user agents and proxies/gateways to other Internet systems, including those supported by the SMTP [16], NNTP [13], FTP [18], Gopher [2], and WAIS [10] protocols. In this way, HTTP allows basic hypermedia access to resources available from diverse applications.

1.2. Requirements

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [34].

An implementation is not compliant if it fails to satisfy one or more of the MUST or REQUIRED level requirements for the protocols it implements. An implementation that satisfies all the MUST or REQUIRED level and all the SHOULD level requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the MUST level requirements but not all the SHOULD level requirements for its protocols is said to be "conditionally compliant."

1.3. Terminology

This specification uses a number of terms to refer to the roles played by participants in, and objects of, the HTTP communication.


  • A transport layer virtual circuit established between two programs for the purpose of communication.


  • The basic unit of HTTP communication, consisting of a structured sequence of octets matching the syntax defined in Section 4 and transmitted via the connection.


  • An HTTP request message, as defined in Section 5.


  • An HTTP response message, as defined in Section 6.


  • A network data object or service that can be identified by a URI, as defined in Section 3.2. Resources may be available in multiple representations (e.g. multiple languages, data formats, size, and resolutions) or vary in other ways.


  • The information transferred as the payload of a request or response. An entity consists of metainformation in the form of entity-header fields and content in the form of an entity-body, as described in Section 7.


  • An entity included with a response that is subject to content negotiation, as described in Section 12. There may exist multiple representations associated with a particular response status.

content negotiation

  • The mechanism for selecting the appropriate representation when servicing a request, as described in Section 12. The representation of entities in any response can be negotiated (including error responses).


  • A resource may have one, or more than one, representation(s) associated with it at any given instant. Each of these representations is termed a `var I riant'. Use of the term `variant' does not necessarily imply that the resource is subject to content negotiation.


  • A program that establishes connections for the purpose of sending requests.

user agent

  • The client which initiates a request. These are often browsers, editors, spiders (web-traversing robots), or other end user tools.


  • An application program that accepts connections in order to service requests by sending back responses. Any given program may be capable of being both a client and a server; our use of these terms refers only to the role being performed by the program for a particular connection, rather than to the program's capabilities in general. Likewise, any server may act as an origin server, proxy, gateway, or tunnel, switching behavior based on the nature of each request.

origin server

  • The server on which a given resource resides or is to be created.


  • An intermediary program which acts as both a server and a client for the purpose of making requests on behalf of other clients. Requests are serviced internally or by passing them on, with possible translation, to other servers. A proxy MUST implement both the client and server requirements of this specification. A "transparent proxy" is a proxy that does not modify the request or response beyond what is required for proxy authentication and identification. A "non-transparent proxy" is a proxy that modifies the request or response in order to provide some added service to the user agent, such as group annotation services, media type transformation, protocol reduction, or anonymity filtering. Except where either transparent or non-transparent behavior is explicitly stated, the HTTP proxy requirements apply to both types of proxies.


  • A server which acts as an intermediary for some other server. Unlike a proxy, a gateway receives requests as if it were the origin server for the requested resource; the requesting client may not be aware that it is communicating with a gateway.


  • An intermediary program which is acting as a blind relay between two connections. Once active, a tunnel is not considered a party to the HTTP communication, though the tunnel may have been initiated by an HTTP request. The tunnel ceases to exist when both ends of the relayed connections are closed.


  • A program's local store of response messages and the subsystem that controls its message storage, retrieval, and deletion. A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent requests. Any client or server may include a cache, though a cache cannot be used by a server that is acting as a tunnel.


  • A response is cacheable if a cache is allowed to store a copy of the response message for use in answering subsequent requests. The rules for determining the cacheability of HTTP responses are defined in Section 13. Even if a resource is cacheable, there may be additional constraints on whether a cache can use the cached copy for a particular request.


  • A response is first-hand if it comes directly and without unnecessary delay from the origin server, perhaps via one or more proxies. A