Source: http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-02.html
Timestamp: 2014-11-21 02:08:56
Document Index: 469427833

Matched Legal Cases: ['art 1', 'art 1', 'art 1', 'art 1', 'art 1', 'art 1', 'art3', 'art3', 'art3', 'art6', 'art3', 'art6', 'art3']

HTTP/1.1, part 1: URIs, Connections, and Message ParsingNetwork Working GroupR. Fielding, EditorInternet-DraftDay SoftwareObsoletes: 2616 (if approved)J. GettysIntended status: Standards TrackOne Laptop per ChildExpires: August 27, 2008J. MogulHPH. FrystykMicrosoftL. MasinterAdobe SystemsP. LeachMicrosoftT. Berners-LeeW3C/MITY. Lafon, EditorW3CJ. Reschke, EditorgreenbytesFebruary 24, 2008HTTP/1.1, part 1: URIs, Connections, and Message Parsingdraft-ietf-httpbis-p1-messaging-02Status of this MemoBy 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 http://www.ietf.org/ietf/1id-abstracts.txt.The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.This Internet-Draft will expire on August 27, 2008.AbstractThe 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. This document is Part 1 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides an overview of HTTP and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the generic message syntax and parsing requirements for HTTP message frames, and describes general security concerns for implementations.Editorial Note (To be removed by RFC Editor)Discussion of this draft should take place on the HTTPBIS working group mailing list (ietf-http-wg@w3.org). The current issues list is at <http://www.tools.ietf.org/wg/httpbis/trac/report/11> and related documents (including fancy diffs) can be found at <http://www.tools.ietf.org/wg/httpbis/>.This draft incorporates those issue resolutions that were either collected in the original RFC2616 errata list (<http://purl.org/NET/http-errata>), or which were agreed upon on the mailing list between October 2006 and November 2007 (as published in "draft-lafon-rfc2616bis-03").Table of Contents1. Introduction1.1 Purpose1.2 Requirements1.3 Terminology1.4 Overall Operation2. Notational Conventions and Generic Grammar2.1 Augmented BNF2.2 Basic Rules2.3 ABNF Rules defined in other Parts of the Specification3. Protocol Parameters3.1 HTTP Version3.2 Uniform Resource Identifiers3.2.1 General Syntax3.2.2 http URL3.2.3 URI Comparison3.3 Date/Time Formats3.3.1 Full Date3.4 Transfer Codings3.4.1 Chunked Transfer Coding3.5 Product Tokens4. HTTP Message4.1 Message Types4.2 Message Headers4.3 Message Body4.4 Message Length4.5 General Header Fields5. Request5.1 Request-Line5.1.1 Method5.1.2 Request-URI5.2 The Resource Identified by a Request6. Response6.1 Status-Line6.1.1 Status Code and Reason Phrase7. Connections7.1 Persistent Connections7.1.1 Purpose7.1.2 Overall Operation7.1.3 Proxy Servers7.1.4 Practical Considerations7.2 Message Transmission Requirements7.2.1 Persistent Connections and Flow Control7.2.2 Monitoring Connections for Error Status Messages7.2.3 Use of the 100 (Continue) Status7.2.4 Client Behavior if Server Prematurely Closes Connection8. Header Field Definitions8.1 Connection8.2 Content-Length8.3 Date8.3.1 Clockless Origin Server Operation8.4 Host8.5 TE8.6 Trailer8.7 Transfer-Encoding8.8 Upgrade8.9 Via9. IANA Considerations10. Security Considerations10.1 Personal Information10.2 Abuse of Server Log Information10.3 Attacks Based On File and Path Names10.4 DNS Spoofing10.5 Proxies and Caching10.6 Denial of Service Attacks on Proxies11. Acknowledgments12. References12.1 Normative References12.2 Informative ReferencesA. Internet Media TypesA.1 Internet Media Type message/httpA.2 Internet Media Type application/httpB. Tolerant ApplicationsC. Conversion of Date FormatsD. Compatibility with Previous VersionsD.1 Changes from HTTP/1.0D.1.1 Changes to Simplify Multi-homed Web Servers and Conserve IP AddressesD.2 Compatibility with HTTP/1.0 Persistent ConnectionsD.3 Changes from RFC 2068D.4 Changes from RFC 2616E. Change Log (to be removed by RFC Editor before publication)E.1 Since RFC2616E.2 Since draft-ietf-httpbis-p1-messaging-00E.3 Since draft-ietf-httpbis-p1-messaging-01IndexAuthors' AddressesIntellectual Property and Copyright Statements1. IntroductionThe 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, commonly referred to as HTTP/0.9, was a simple protocol for raw data transfer across the Internet with only a single method and no metadata. HTTP/1.0, as defined by [RFC1945], improved the protocol by allowing messages to be in the format of MIME-like messages, containing metadata about the data transferred and modifiers on the request/response semantics. However, HTTP/1.0 did not sufficiently take into consideration the effects of hierarchical proxies, caching, the need for persistent connections, or name-based virtual hosts. In addition, the proliferation of incompletely-implemented applications calling themselves "HTTP/1.0" necessitated a protocol version change in order for two communicating applications to determine each other's true capabilities.¶This document is Part 1 of the seven-part specification that defines the protocol referred to as "HTTP/1.1", obsoleting [RFC2616]. HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent requirements that enable reliable implementations and adding only those new features that will either be safely ignored by an HTTP/1.0 recipient or only sent when communicating with a party advertising compliance with HTTP/1.1. Part 1 defines those aspects of HTTP/1.1 related to overall network operation, message framing, interaction with transport protocols, and URI schemes.¶This document is currently disorganized in order to minimize the changes between drafts and enable reviewers to see the smaller errata changes. The next draft will reorganize the sections to better reflect the content. In particular, the sections will be organized according to the typical process of deciding when to use HTTP (URI schemes), overall network operation, connection management, message framing, and generic message parsing. The current mess reflects how widely dispersed these topics and associated requirements had become in [RFC2616].¶1.1 PurposePractical 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 [RFC2324]. It builds on the discipline of reference provided by the Uniform Resource Identifier (URI) [RFC1630], as a location (URL) [RFC1738] or name (URN) [RFC1737], 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 [RFC2822] as defined by the Multipurpose Internet Mail Extensions (MIME) [RFC2045].¶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 [RFC2821], NNTP [RFC3977], FTP [RFC959], Gopher [RFC1436], and WAIS [WAIS] protocols. In this way, HTTP allows basic hypermedia access to resources available from diverse applications.¶1.2 RequirementsThe 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 [RFC2119].¶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 TerminologyThis specification uses a number of terms to refer to the roles played by participants in, and objects of, the HTTP communication.¶ connection ¶A transport layer virtual circuit established between two programs for the purpose of communication. message ¶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. request ¶An HTTP request message, as defined in Section 5. response ¶An HTTP response message, as defined in Section 6. resource ¶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. entity ¶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 4 of [Part3]. representation ¶An entity included with a response that is subject to content negotiation, as described in Section 5 of [Part3]. 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 5 of [Part3]. The representation of entities in any response can be negotiated (including error responses). variant ¶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 `variant'. Use of the term `variant' does not necessarily imply that the resource is subject to content negotiation. client ¶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. server ¶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. proxy ¶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. gateway ¶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. tunnel ¶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. cache ¶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. cacheable ¶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 1 of [Part6]. Even if a resource is cacheable, there may be additional constraints on whether a cache can use the cached copy for a particular request. upstream/downstream ¶Upstream and downstream describe the flow of a message: all messages flow from upstream to downstream. inbound/outbound ¶Inbound and outbound refer to the request and response paths for messages: "inbound" means "traveling toward the origin server", and "outbound" means "traveling toward the user agent"1.4 Overall OperationHTTP is a request/response protocol. A client sends a request to the server in the form of a request method, URI, and protocol version, followed by a MIME-like message containing request modifiers, client information, and possible body content over a connection with a server. The server responds with a status line, including the message's protocol version and a success or error code, followed by a MIME-like message containing server information, entity metainformation, and possible entity-body content. The relationship between HTTP and MIME is described in Appendix A of [Part3].¶Most HTTP communication is initiated by a user agent and consists of a request to be applied to a resource on some origin server. In the simplest case, this may be accomplished via a single connection (v) between the user agent (UA) and the origin server (O).¶       request chain ------------------------&gt;
Not all responses are usefully cacheable, and some requests may contain modifiers which place special requirements on cache behavior. HTTP requirements for cache behavior and cacheable responses are defined in Section 1 of [Part6].¶In fact, there are a wide variety of architectures and configurations of caches and proxies currently being experimented with or deployed across the World Wide Web. These systems include national hierarchies of proxy caches to save transoceanic bandwidth, systems that broadcast or multicast cache entries, organizations that distribute subsets of cached data via CD-ROM, and so on. HTTP systems are used in corporate intranets over high-bandwidth links, and for access via PDAs with low-power radio links and intermittent connectivity. The goal of HTTP/1.1 is to support the wide diversity of configurations already deployed while introducing protocol constructs that meet the needs of those who build web applications that require high reliability and, failing that, at least reliable indications of failure.¶HTTP communication usually takes place over TCP/IP connections. The default port is TCP 80 (<http://www.iana.org/assignments/port-numbers>), but other ports can be used. This does not preclude HTTP from being implemented on top of any other protocol on the Internet, or on other networks. HTTP only presumes a reliable transport; any protocol that provides such guarantees can be used; the mapping of the HTTP/1.1 request and response structures onto the transport data units of the protocol in question is outside the scope of this specification.¶In HTTP/1.0, most implementations used a new connection for each request/response exchange. In HTTP/1.1, a connection may be used for one or more request/response exchanges, although connections may be closed for a variety of reasons (see Section 7.1).¶2. Notational Conventions and Generic Grammar2.1 Augmented BNFAll of the mechanisms specified in this document are described in both prose and an augmented Backus-Naur Form (BNF) similar to that used by [RFC822ABNF]. Implementors will need to be familiar with the notation in order to understand this specification. The augmented BNF includes the following constructs:¶name = definition ¶The name of a rule is simply the name itself (without any enclosing "<" and ">") and is separated from its definition by the equal "=" character. White space is only significant in that indentation of continuation lines is used to indicate a rule definition that spans more than one line. Certain basic rules are in uppercase, such as SP, LWS, HTAB, CRLF, DIGIT, ALPHA, etc. Angle brackets are used within definitions whenever their presence will facilitate discerning the use of rule names."literal" ¶Quotation marks surround literal text. Unless stated otherwise, the text is case-insensitive.rule1 | rule2 ¶Elements separated by a bar ("|") are alternatives, e.g., "yes | no" will accept yes or no.(rule1 rule2) ¶Elements enclosed in parentheses are treated as a single element. Thus, "(elem (foo | bar) elem)" allows the token sequences "elem foo elem" and "elem bar elem".*rule ¶The character "*" preceding an element indicates repetition. The full form is "<n>*<m>element" indicating at least <n> and at most <m> occurrences of element. Default values are 0 and infinity so that "*(element)" allows any number, including zero; "1*element" requires at least one; and "1*2element" allows one or two.[rule] ¶Square brackets enclose optional elements; "[foo bar]" is equivalent to "*1(foo bar)".N rule ¶Specific repetition: "<n>(element)" is equivalent to "<n>*<n>(element)"; that is, exactly <n> occurrences of (element). Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three alphabetic characters.#rule ¶A construct "#" is defined, similar to "*", for defining lists of elements. The full form is "<n>#<m>element" indicating at least <n> and at most <m> elements, each separated by one or more commas (",") and OPTIONAL linear white space (LWS). This makes the usual form of lists very easy; a rule such as( *LWS element *( *LWS "," *LWS element ))can be shown as1#elementWherever this construct is used, null elements are allowed, but do not contribute to the count of elements present. That is, "(element), , (element) " is permitted, but counts as only two elements. Therefore, where at least one element is required, at least one non-null element MUST be present. Default values are 0 and infinity so that "#element" allows any number, including zero; "1#element" requires at least one; and "1#2element" allows one or two.; comment ¶A semi-colon, set off some distance to the right of rule text, starts a comment that continues to the end of line. This is a simple way of including useful notes in parallel with the specifications.implied *LWS ¶The grammar described by this specification is word-based. Except where noted otherwise, linear white space (LWS) can be included between any two adjacent words (token or quoted-string), and between adjacent words and separators, without changing the interpretation of a field. At least one delimiter (LWS and/or separators) MUST exist between any two tokens (for the definition of "token" below), since they would otherwise be interpreted as a single token.2.2 Basic RulesThe following rules are used throughout this specification to describe basic parsing constructs. The US-ASCII coded character set is defined by ANSI X3.4-1986 [USASCII].¶  OCTET          = %x00-FF
HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all protocol elements except the entity-body (see Appendix B for tolerant applications). The end-of-line marker within an entity-body is defined by its associated media type, as described in Section 3.3 of [Part3].¶  CRLF           = CR LF
HTTP/1.1 header field values can be folded onto multiple lines if the continuation line begins with a space or horizontal tab. All linear white space, including folding, has the same semantics as SP. A recipient MAY replace any linear white space with a single SP before interpreting the field value or forwarding the message downstream.¶  LWS            = [CRLF] 1*( SP | HTAB )
The TEXT rule is only used for descriptive field contents and values that are not intended to be interpreted by the message parser. Words of *TEXT MAY contain characters from character sets other than ISO-8859-1 [ISO-8859-1] only when encoded according to the rules of [RFC2047].¶  TEXT           = %x20-7E | %x80-FF | LWS
A CRLF is allowed in the definition of TEXT only as part of a header field continuation. It is expected that the folding LWS will be replaced with a single SP before interpretation of the TEXT value.¶Hexadecimal numeric characters are used in several protocol elements.¶  HEX            = "A" | "B" | "C" | "D" | "E" | "F"
Many HTTP/1.1 header field values consist of words separated by LWS or special characters. These special characters MUST be in a quoted string to be used within a parameter value (as defined in Section 3.4).¶  separators     = "(" | ")" | "&lt;" | "&gt;" | "@"
tchar          = "!" | "#" | "$" | "%" | "&amp;" | "'" | "*"
Comments can be included in some HTTP header fields by surrounding the comment text with parentheses. Comments are only allowed in fields containing "comment" as part of their field value definition. In all other fields, parentheses are considered part of the field value.¶  comment        = "(" *( ctext | quo