diff options
Diffstat (limited to 'vendor/sabre/dav/docs/draft-ietf-httpbis-p1-messaging-11.txt')
| -rw-r--r-- | vendor/sabre/dav/docs/draft-ietf-httpbis-p1-messaging-11.txt | 5152 |
1 files changed, 5152 insertions, 0 deletions
diff --git a/vendor/sabre/dav/docs/draft-ietf-httpbis-p1-messaging-11.txt b/vendor/sabre/dav/docs/draft-ietf-httpbis-p1-messaging-11.txt new file mode 100644 index 000000000..c0d449877 --- /dev/null +++ b/vendor/sabre/dav/docs/draft-ietf-httpbis-p1-messaging-11.txt @@ -0,0 +1,5152 @@ + + + +HTTPbis Working Group R. Fielding, Ed. +Internet-Draft Day Software +Obsoletes: 2616 (if approved) J. Gettys +Updates: 2817 (if approved) Alcatel-Lucent +Intended status: Standards Track J. Mogul +Expires: February 5, 2011 HP + H. Frystyk + Microsoft + L. Masinter + Adobe Systems + P. Leach + Microsoft + T. Berners-Lee + W3C/MIT + Y. Lafon, Ed. + W3C + J. Reschke, Ed. + greenbytes + August 4, 2010 + + + HTTP/1.1, part 1: URIs, Connections, and Message Parsing + draft-ietf-httpbis-p1-messaging-11 + +Abstract + + The Hypertext Transfer Protocol (HTTP) is an application-level + protocol for distributed, collaborative, hypertext 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://tools.ietf.org/wg/httpbis/trac/report/3> and related + documents (including fancy diffs) can be found at + <http://tools.ietf.org/wg/httpbis/>. + + The changes in this draft are summarized in Appendix D.12. + +Status of This Memo + + + +Fielding, et al. Expires February 5, 2011 [Page 1] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + This Internet-Draft is submitted in full conformance with the + provisions of BCP 78 and BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF). Note that other groups may also distribute + working documents as Internet-Drafts. The list of current Internet- + Drafts is at http://datatracker.ietf.org/drafts/current/. + + 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." + + This Internet-Draft will expire on February 5, 2011. + +Copyright Notice + + Copyright (c) 2010 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7 + 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7 + 1.2.1. ABNF Extension: #rule . . . . . . . . . . . . . . . . 7 + + + +Fielding, et al. Expires February 5, 2011 [Page 2] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + 1.2.2. Basic Rules . . . . . . . . . . . . . . . . . . . . . 8 + 1.2.3. ABNF Rules defined in other Parts of the + Specification . . . . . . . . . . . . . . . . . . . . 10 + 2. HTTP-related architecture . . . . . . . . . . . . . . . . . . 10 + 2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 10 + 2.2. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 12 + 2.3. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 2.4. Transport Independence . . . . . . . . . . . . . . . . . . 14 + 2.5. HTTP Version . . . . . . . . . . . . . . . . . . . . . . . 14 + 2.6. Uniform Resource Identifiers . . . . . . . . . . . . . . . 16 + 2.6.1. http URI scheme . . . . . . . . . . . . . . . . . . . 16 + 2.6.2. https URI scheme . . . . . . . . . . . . . . . . . . . 18 + 2.6.3. http and https URI Normalization and Comparison . . . 18 + 3. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 3.1. Message Parsing Robustness . . . . . . . . . . . . . . . . 20 + 3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 20 + 3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 22 + 3.4. General Header Fields . . . . . . . . . . . . . . . . . . 25 + 4. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 + 4.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 26 + 4.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 26 + 4.1.2. request-target . . . . . . . . . . . . . . . . . . . . 27 + 4.2. The Resource Identified by a Request . . . . . . . . . . . 29 + 4.3. Effective Request URI . . . . . . . . . . . . . . . . . . 29 + 5. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 + 5.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 31 + 5.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 31 + 6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 32 + 6.1. Date/Time Formats: Full Date . . . . . . . . . . . . . . . 32 + 6.2. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 34 + 6.2.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 35 + 6.2.2. Compression Codings . . . . . . . . . . . . . . . . . 37 + 6.2.3. Transfer Coding Registry . . . . . . . . . . . . . . . 38 + 6.3. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 39 + 6.4. Quality Values . . . . . . . . . . . . . . . . . . . . . . 39 + 7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 39 + 7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 39 + 7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 40 + 7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 40 + 7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 42 + 7.1.4. Practical Considerations . . . . . . . . . . . . . . . 44 + 7.2. Message Transmission Requirements . . . . . . . . . . . . 45 + 7.2.1. Persistent Connections and Flow Control . . . . . . . 45 + 7.2.2. Monitoring Connections for Error Status Messages . . . 45 + 7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 46 + 7.2.4. Client Behavior if Server Prematurely Closes + Connection . . . . . . . . . . . . . . . . . . . . . . 48 + 8. Miscellaneous notes that might disappear . . . . . . . . . . . 49 + + + +Fielding, et al. Expires February 5, 2011 [Page 3] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + 8.1. Scheme aliases considered harmful . . . . . . . . . . . . 49 + 8.2. Use of HTTP for proxy communication . . . . . . . . . . . 49 + 8.3. Interception of HTTP for access control . . . . . . . . . 49 + 8.4. Use of HTTP by other protocols . . . . . . . . . . . . . . 49 + 8.5. Use of HTTP by media type specification . . . . . . . . . 49 + 9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 49 + 9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 49 + 9.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 50 + 9.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 + 9.3.1. Clockless Origin Server Operation . . . . . . . . . . 52 + 9.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 + 9.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 + 9.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 54 + 9.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 55 + 9.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 55 + 9.8.1. Upgrade Token Registry . . . . . . . . . . . . . . . . 56 + 9.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59 + 10.1. Header Field Registration . . . . . . . . . . . . . . . . 59 + 10.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 59 + 10.3. Internet Media Type Registrations . . . . . . . . . . . . 59 + 10.3.1. Internet Media Type message/http . . . . . . . . . . . 59 + 10.3.2. Internet Media Type application/http . . . . . . . . . 61 + 10.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 62 + 10.5. Upgrade Token Registration . . . . . . . . . . . . . . . . 62 + 11. Security Considerations . . . . . . . . . . . . . . . . . . . 62 + 11.1. Personal Information . . . . . . . . . . . . . . . . . . . 63 + 11.2. Abuse of Server Log Information . . . . . . . . . . . . . 63 + 11.3. Attacks Based On File and Path Names . . . . . . . . . . . 63 + 11.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 63 + 11.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 64 + 11.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 65 + 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 65 + 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 66 + 13.1. Normative References . . . . . . . . . . . . . . . . . . . 66 + 13.2. Informative References . . . . . . . . . . . . . . . . . . 68 + Appendix A. Tolerant Applications . . . . . . . . . . . . . . . . 70 + Appendix B. Compatibility with Previous Versions . . . . . . . . 71 + B.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 71 + B.1.1. Changes to Simplify Multi-homed Web Servers and + Conserve IP Addresses . . . . . . . . . . . . . . . . 72 + B.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 72 + B.3. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 73 + Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 74 + Appendix D. Change Log (to be removed by RFC Editor before + publication) . . . . . . . . . . . . . . . . . . . . 78 + D.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 78 + D.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 78 + + + +Fielding, et al. Expires February 5, 2011 [Page 4] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + D.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 80 + D.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 81 + D.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 81 + D.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 82 + D.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 82 + D.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 83 + D.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 84 + D.10. Since draft-ietf-httpbis-p1-messaging-08 . . . . . . . . . 84 + D.11. Since draft-ietf-httpbis-p1-messaging-09 . . . . . . . . . 85 + D.12. Since draft-ietf-httpbis-p1-messaging-10 . . . . . . . . . 85 + Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Fielding, et al. Expires February 5, 2011 [Page 5] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + +1. Introduction + + The Hypertext Transfer Protocol (HTTP) is an application-level + request/response protocol that uses extensible semantics and MIME- + like message payloads for flexible interaction with network-based + hypertext information systems. HTTP relies upon the Uniform Resource + Identifier (URI) standard [RFC3986] to indicate request targets and + relationships between resources. Messages are passed in a format + similar to that used by Internet mail [RFC5322] and the Multipurpose + Internet Mail Extensions (MIME) [RFC2045] (see Appendix A of [Part3] + for the differences between HTTP and MIME messages). + + HTTP is a generic interface protocol for information systems. It is + designed to hide the details of how a service is implemented by + presenting a uniform interface to clients that is independent of the + types of resources provided. Likewise, servers do not need to be + aware of each client's purpose: an HTTP request can be considered in + isolation rather than being associated with a specific type of client + or a predetermined sequence of application steps. The result is a + protocol that can be used effectively in many different contexts and + for which implementations can evolve independently over time. + + HTTP is also designed for use as an intermediation protocol for + translating communication to and from non-HTTP information systems. + HTTP proxies and gateways can provide access to alternative + information services by translating their diverse protocols into a + hypertext format that can be viewed and manipulated by clients in the + same way as HTTP services. + + One consequence of HTTP flexibility is that the protocol cannot be + defined in terms of what occurs behind the interface. Instead, we + are limited to defining the syntax of communication, the intent of + received communication, and the expected behavior of recipients. If + the communication is considered in isolation, then successful actions + ought to be reflected in corresponding changes to the observable + interface provided by servers. However, since multiple clients might + act in parallel and perhaps at cross-purposes, we cannot require that + such changes be observable beyond the scope of a single response. + + This document is Part 1 of the seven-part specification of HTTP, + defining the protocol referred to as "HTTP/1.1" and obsoleting + [RFC2616]. Part 1 describes the architectural elements that are used + or referred to in HTTP, defines the "http" and "https" URI schemes, + describes overall network operation and connection management, and + defines HTTP message framing and forwarding requirements. Our goal + is to define all of the mechanisms necessary for HTTP message + handling that are independent of message semantics, thereby defining + the complete set of requirements for message parsers and message- + + + +Fielding, et al. Expires February 5, 2011 [Page 6] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + forwarding intermediaries. + +1.1. 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 [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.2. Syntax Notation + + This specification uses the Augmented Backus-Naur Form (ABNF) + notation of [RFC5234]. + + The following core rules are included by reference, as defined in + [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF + (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), + HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit + sequence of data), SP (space), VCHAR (any visible [USASCII] + character), and WSP (whitespace). + + As a syntactic convention, ABNF rule names prefixed with "obs-" + denote "obsolete" grammar rules that appear for historical reasons. + +1.2.1. ABNF Extension: #rule + + The #rule extension to the ABNF rules of [RFC5234] is used to improve + readability. + + A construct "#" is defined, similar to "*", for defining comma- + delimited lists of elements. The full form is "<n>#<m>element" + indicating at least <n> and at most <m> elements, each separated by a + single comma (",") and optional whitespace (OWS, Section 1.2.2). + + Thus, + + 1#element => element *( OWS "," OWS element ) + + + + + + +Fielding, et al. Expires February 5, 2011 [Page 7] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + and: + + #element => [ 1#element ] + + and for n >= 1 and m > 1: + + <n>#<m>element => element <n-1>*<m-1>( OWS "," OWS element ) + + For compatibility with legacy list rules, recipients SHOULD accept + empty list elements. In other words, consumers would follow the list + productions: + + #element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ] + + 1#element => *( "," OWS ) element *( OWS "," [ OWS element ] ) + + Note that empty elements do not contribute to the count of elements + present, though. + + For example, given these ABNF productions: + + example-list = 1#example-list-elmt + example-list-elmt = token ; see Section 1.2.2 + + Then these are valid values for example-list (not including the + double quotes, which are present for delimitation only): + + "foo,bar" + " foo ,bar," + " foo , ,bar,charlie " + "foo ,bar, charlie " + + But these values would be invalid, as at least one non-empty element + is required: + + "" + "," + ", ," + + Appendix C shows the collected ABNF, with the list rules expanded as + explained above. + +1.2.2. Basic Rules + + HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all + protocol elements other than the message-body (see Appendix A for + tolerant applications). + + + + +Fielding, et al. Expires February 5, 2011 [Page 8] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + This specification uses three rules to denote the use of linear + whitespace: OWS (optional whitespace), RWS (required whitespace), and + BWS ("bad" whitespace). + + The OWS rule is used where zero or more linear whitespace characters + might appear. OWS SHOULD either not be produced or be produced as a + single SP character. Multiple OWS characters that occur within + field-content SHOULD be replaced with a single SP before interpreting + the field value or forwarding the message downstream. + + RWS is used when at least one linear whitespace character is required + to separate field tokens. RWS SHOULD be produced as a single SP + character. Multiple RWS characters that occur within field-content + SHOULD be replaced with a single SP before interpreting the field + value or forwarding the message downstream. + + BWS is used where the grammar allows optional whitespace for + historical reasons but senders SHOULD NOT produce it in messages. + HTTP/1.1 recipients MUST accept such bad optional whitespace and + remove it before interpreting the field value or forwarding the + message downstream. + + + OWS = *( [ obs-fold ] WSP ) + ; "optional" whitespace + RWS = 1*( [ obs-fold ] WSP ) + ; "required" whitespace + BWS = OWS + ; "bad" whitespace + obs-fold = CRLF + ; see Section 3.2 + + Many HTTP/1.1 header field values consist of words (token or quoted- + string) separated by whitespace or special characters. These special + characters MUST be in a quoted string to be used within a parameter + value (as defined in Section 6.2). + + word = token / quoted-string + + token = 1*tchar + + tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" + / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" + / DIGIT / ALPHA + ; any VCHAR, except special + + special = "(" / ")" / "<" / ">" / "@" / "," + / ";" / ":" / "\" / DQUOTE / "/" / "[" + + + +Fielding, et al. Expires February 5, 2011 [Page 9] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + / "]" / "?" / "=" / "{" / "}" + + A string of text is parsed as a single word if it is quoted using + double-quote marks. + + quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE + qdtext = OWS / %x21 / %x23-5B / %x5D-7E / obs-text + ; OWS / <VCHAR except DQUOTE and "\"> / obs-text + obs-text = %x80-FF + + The backslash character ("\") can be used as a single-character + quoting mechanism within quoted-string constructs: + + quoted-pair = "\" ( WSP / VCHAR / obs-text ) + + Producers SHOULD NOT escape characters that do not require escaping + (i.e., other than DQUOTE and the backslash character). + +1.2.3. ABNF Rules defined in other Parts of the Specification + + The ABNF rules below are defined in other parts: + + request-header = <request-header, defined in [Part2], Section 3> + response-header = <response-header, defined in [Part2], Section 5> + + + MIME-Version = <MIME-Version, defined in [Part3], Appendix A.1> + + + Cache-Control = <Cache-Control, defined in [Part6], Section 3.4> + Pragma = <Pragma, defined in [Part6], Section 3.4> + Warning = <Warning, defined in [Part6], Section 3.6> + +2. HTTP-related architecture + + HTTP was created for the World Wide Web architecture and has evolved + over time to support the scalability needs of a worldwide hypertext + system. Much of that architecture is reflected in the terminology + and syntax productions used to define HTTP. + +2.1. Client/Server Messaging + + HTTP is a stateless request/response protocol that operates by + exchanging messages across a reliable transport or session-layer + connection. An HTTP "client" is a program that establishes a + connection to a server for the purpose of sending one or more HTTP + requests. An HTTP "server" is a program that accepts connections in + order to service HTTP requests by sending HTTP responses. + + + +Fielding, et al. Expires February 5, 2011 [Page 10] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + Note that the terms client and server refer only to the roles that + these programs perform for a particular connection. The same program + might act as a client on some connections and a server on others. We + use the term "user agent" to refer to the program that initiates a + request, such as a WWW browser, editor, or spider (web-traversing + robot), and the term "origin server" to refer to the program that can + originate authoritative responses to a request. For general + requirements, we use the term "sender" to refer to whichever + component sent a given message and the term "recipient" to refer to + any component that receives the message. + + Most HTTP communication consists of a retrieval request (GET) for a + representation of some resource identified by a URI. In the simplest + case, this might be accomplished via a single bidirectional + connection (===) between the user agent (UA) and the origin server + (O). + + request > + UA ======================================= O + < response + + A client sends an HTTP request to the server in the form of a request + message (Section 4), beginning with a method, URI, and protocol + version, followed by MIME-like header fields containing request + modifiers, client information, and payload metadata, an empty line to + indicate the end of the header section, and finally the payload body + (if any). + + A server responds to the client's request by sending an HTTP response + message (Section 5), beginning with a status line that includes the + protocol version, a success or error code, and textual reason phrase, + followed by MIME-like header fields containing server information, + resource metadata, and payload metadata, an empty line to indicate + the end of the header section, and finally the payload body (if any). + + The following example illustrates a typical message exchange for a + GET request on the URI "http://www.example.com/hello.txt": + + client request: + + GET /hello.txt HTTP/1.1 + User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3 + Host: www.example.com + Accept: */* + + + + + + + +Fielding, et al. Expires February 5, 2011 [Page 11] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + server response: + + HTTP/1.1 200 OK + Date: Mon, 27 Jul 2009 12:28:53 GMT + Server: Apache + Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT + ETag: "34aa387-d-1568eb00" + Accept-Ranges: bytes + Content-Length: 14 + Vary: Accept-Encoding + Content-Type: text/plain + + Hello World! + +2.2. Intermediaries + + A more complicated situation occurs when one or more intermediaries + are present in the request/response chain. There are three common + forms of intermediary: proxy, gateway, and tunnel. In some cases, a + single intermediary might act as an origin server, proxy, gateway, or + tunnel, switching behavior based on the nature of each request. + + > > > > + UA =========== A =========== B =========== C =========== O + < < < < + + The figure above shows three intermediaries (A, B, and C) between the + user agent and origin server. A request or response message that + travels the whole chain will pass through four separate connections. + Some HTTP communication options might apply only to the connection + with the nearest, non-tunnel neighbor, only to the end-points of the + chain, or to all connections along the chain. Although the diagram + is linear, each participant might be engaged in multiple, + simultaneous communications. For example, B might be receiving + requests from many clients other than A, and/or forwarding requests + to servers other than C, at the same time that it is handling A's + request. + + We use the terms "upstream" and "downstream" to describe various + requirements in relation to the directional flow of a message: all + messages flow from upstream to downstream. Likewise, we use the + terms "inbound" and "outbound" to refer to directions in relation to + the request path: "inbound" means toward the origin server and + "outbound" means toward the user agent. + + A "proxy" is a message forwarding agent that is selected by the + client, usually via local configuration rules, to receive requests + for some type(s) of absolute URI and attempt to satisfy those + + + +Fielding, et al. Expires February 5, 2011 [Page 12] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + requests via translation through the HTTP interface. Some + translations are minimal, such as for proxy requests for "http" URIs, + whereas other requests might require translation to and from entirely + different application-layer protocols. Proxies are often used to + group an organization's HTTP requests through a common intermediary + for the sake of security, annotation services, or shared caching. + + A "gateway" (a.k.a., "reverse proxy") is a receiving agent that acts + as a layer above some other server(s) and translates the received + requests to the underlying server's protocol. Gateways are often + used for load balancing or partitioning HTTP services across multiple + machines. Unlike a proxy, a gateway receives requests as if it were + the origin server for the target resource; the requesting client will + not be aware that it is communicating with a gateway. A gateway + communicates with the client as if the gateway is the origin server + and thus is subject to all of the requirements on origin servers for + that connection. A gateway communicates with inbound servers using + any protocol it desires, including private extensions to HTTP that + are outside the scope of this specification. + + A "tunnel" acts as a blind relay between two connections without + changing the messages. Once active, a tunnel is not considered a + party to the HTTP communication, though the tunnel might have been + initiated by an HTTP request. A tunnel ceases to exist when both + ends of the relayed connection are closed. Tunnels are used to + extend a virtual connection through an intermediary, such as when + transport-layer security is used to establish private communication + through a shared firewall proxy. + +2.3. Caches + + A "cache" is a local store of previous 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 employ a cache, though a cache + cannot be used by a server while it is acting as a tunnel. + + The effect of a cache is that the request/response chain is shortened + if one of the participants along the chain has a cached response + applicable to that request. The following illustrates the resulting + chain if B has a cached copy of an earlier response from O (via C) + for a request which has not been cached by UA or A. + + > > + UA =========== A =========== B - - - - - - C - - - - - - O + < < + + + + +Fielding, et al. Expires February 5, 2011 [Page 13] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + A response is "cacheable" if a cache is allowed to store a copy of + the response message for use in answering subsequent requests. Even + when a response is cacheable, there might be additional constraints + placed by the client or by the origin server on when that cached + response can be used for a particular request. HTTP requirements for + cache behavior and cacheable responses are defined in Section 2 of + [Part6]. + + There are a wide variety of architectures and configurations of + caches and proxies deployed across the World Wide Web and inside + large organizations. 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 optical media, and so on. + +2.4. Transport Independence + + HTTP systems are used in a wide variety of environments, from + corporate intranets with high-bandwidth links to long-distance + communication over low-power radio links and intermittent + connectivity. + + 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 might be used + for one or more request/response exchanges, although connections + might be closed for a variety of reasons (see Section 7.1). + +2.5. HTTP Version + + HTTP uses a "<major>.<minor>" numbering scheme to indicate versions + of the protocol. The protocol versioning policy is intended to allow + the sender to indicate the format of a message and its capacity for + understanding further HTTP communication, rather than the features + obtained via that communication. No change is made to the version + number for the addition of message components which do not affect + communication behavior or which only add to extensible field values. + The <minor> number is incremented when the changes made to the + protocol add features which do not change the general message parsing + + + +Fielding, et al. Expires February 5, 2011 [Page 14] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + algorithm, but which might add to the message semantics and imply + additional capabilities of the sender. The <major> number is + incremented when the format of a message within the protocol is + changed. See [RFC2145] for a fuller explanation. + + The version of an HTTP message is indicated by an HTTP-Version field + in the first line of the message. HTTP-Version is case-sensitive. + + HTTP-Version = HTTP-Prot-Name "/" 1*DIGIT "." 1*DIGIT + HTTP-Prot-Name = %x48.54.54.50 ; "HTTP", case-sensitive + + Note that the major and minor numbers MUST be treated as separate + integers and that each MAY be incremented higher than a single digit. + Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is + lower than HTTP/12.3. Leading zeros MUST be ignored by recipients + and MUST NOT be sent. + + An application that sends a request or response message that includes + HTTP-Version of "HTTP/1.1" MUST be at least conditionally compliant + with this specification. Applications that are at least + conditionally compliant with this specification SHOULD use an HTTP- + Version of "HTTP/1.1" in their messages, and MUST do so for any + message that is not compatible with HTTP/1.0. For more details on + when to send specific HTTP-Version values, see [RFC2145]. + + The HTTP version of an application is the highest HTTP version for + which the application is at least conditionally compliant. + + Proxy and gateway applications need to be careful when forwarding + messages in protocol versions different from that of the application. + Since the protocol version indicates the protocol capability of the + sender, a proxy/gateway MUST NOT send a message with a version + indicator which is greater than its actual version. If a higher + version request is received, the proxy/gateway MUST either downgrade + the request version, or respond with an error, or switch to tunnel + behavior. + + Due to interoperability problems with HTTP/1.0 proxies discovered + since the publication of [RFC2068], caching proxies MUST, gateways + MAY, and tunnels MUST NOT upgrade the request to the highest version + they support. The proxy/gateway's response to that request MUST be + in the same major version as the request. + + Note: Converting between versions of HTTP might involve + modification of header fields required or forbidden by the + versions involved. + + + + + +Fielding, et al. Expires February 5, 2011 [Page 15] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + +2.6. Uniform Resource Identifiers + + Uniform Resource Identifiers (URIs) [RFC3986] are used throughout + HTTP as the means for identifying resources. URI references are used + to target requests, indicate redirects, and define relationships. + HTTP does not limit what a resource might be; it merely defines an + interface that can be used to interact with a resource via HTTP. + More information on the scope of URIs and resources can be found in + [RFC3986]. + + This specification adopts the definitions of "URI-reference", + "absolute-URI", "relative-part", "port", "host", "path-abempty", + "path-absolute", "query", and "authority" from [RFC3986]. In + addition, we define a partial-URI rule for protocol elements that + allow a relative URI without a fragment. + + URI-reference = <URI-reference, defined in [RFC3986], Section 4.1> + absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3> + relative-part = <relative-part, defined in [RFC3986], Section 4.2> + authority = <authority, defined in [RFC3986], Section 3.2> + path-abempty = <path-abempty, defined in [RFC3986], Section 3.3> + path-absolute = <path-absolute, defined in [RFC3986], Section 3.3> + port = <port, defined in [RFC3986], Section 3.2.3> + query = <query, defined in [RFC3986], Section 3.4> + uri-host = <host, defined in [RFC3986], Section 3.2.2> + + partial-URI = relative-part [ "?" query ] + + Each protocol element in HTTP that allows a URI reference will + indicate in its ABNF production whether the element allows only a URI + in absolute form (absolute-URI), any relative reference (relative- + ref), or some other subset of the URI-reference grammar. Unless + otherwise indicated, URI references are parsed relative to the + request target (the default base URI for both the request and its + corresponding response). + +2.6.1. http URI scheme + + The "http" URI scheme is hereby defined for the purpose of minting + identifiers according to their association with the hierarchical + namespace governed by a potential HTTP origin server listening for + TCP connections on a given port. The HTTP server is identified via + the generic syntax's authority component, which includes a host + identifier and optional TCP port, and the remainder of the URI is + considered to be identifying data corresponding to a resource for + which that server might provide an HTTP interface. + + http-URI = "http:" "//" authority path-abempty [ "?" query ] + + + +Fielding, et al. Expires February 5, 2011 [Page 16] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + The host identifier within an authority component is defined in + [RFC3986], Section 3.2.2. If host is provided as an IP literal or + IPv4 address, then the HTTP server is any listener on the indicated + TCP port at that IP address. If host is a registered name, then that + name is considered an indirect identifier and the recipient might use + a name resolution service, such as DNS, to find the address of a + listener for that host. The host MUST NOT be empty; if an "http" URI + is received with an empty host, then it MUST be rejected as invalid. + If the port subcomponent is empty or not given, then TCP port 80 is + assumed (the default reserved port for WWW services). + + Regardless of the form of host identifier, access to that host is not + implied by the mere presence of its name or address. The host might + or might not exist and, even when it does exist, might or might not + be running an HTTP server or listening to the indicated port. The + "http" URI scheme makes use of the delegated nature of Internet names + and addresses to establish a naming authority (whatever entity has + the ability to place an HTTP server at that Internet name or address) + and allows that authority to determine which names are valid and how + they might be used. + + When an "http" URI is used within a context that calls for access to + the indicated resource, a client MAY attempt access by resolving the + host to an IP address, establishing a TCP connection to that address + on the indicated port, and sending an HTTP request message to the + server containing the URI's identifying data as described in + Section 4. If the server responds to that request with a non-interim + HTTP response message, as described in Section 5, then that response + is considered an authoritative answer to the client's request. + + Although HTTP is independent of the transport protocol, the "http" + scheme is specific to TCP-based services because the name delegation + process depends on TCP for establishing authority. An HTTP service + based on some other underlying connection protocol would presumably + be identified using a different URI scheme, just as the "https" + scheme (below) is used for servers that require an SSL/TLS transport + layer on a connection. Other protocols might also be used to provide + access to "http" identified resources --- it is only the + authoritative interface used for mapping the namespace that is + specific to TCP. + + The URI generic syntax for authority also includes a deprecated + userinfo subcomponent ([RFC3986], Section 3.2.1) for including user + authentication information in the URI. The userinfo subcomponent + (and its "@" delimiter) MUST NOT be used in an "http" URI. URI + reference recipients SHOULD parse for the existence of userinfo and + treat its presence as an error, likely indicating that the deprecated + subcomponent is being used to obscure the authority for the sake of + + + +Fielding, et al. Expires February 5, 2011 [Page 17] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + phishing attacks. + +2.6.2. https URI scheme + + The "https" URI scheme is hereby defined for the purpose of minting + identifiers according to their association with the hierarchical + namespace governed by a potential HTTP origin server listening for + SSL/TLS-secured connections on a given TCP port. + + All of the requirements listed above for the "http" scheme are also + requirements for the "https" scheme, except that a default TCP port + of 443 is assumed if the port subcomponent is empty or not given, and + the TCP connection MUST be secured for privacy through the use of + strong encryption prior to sending the first HTTP request. + + https-URI = "https:" "//" authority path-abempty [ "?" query ] + + Unlike the "http" scheme, responses to "https" identified requests + are never "public" and thus are ineligible for shared caching. Their + default is "private" and might be further constrained via use of the + Cache-Control header field. + + Resources made available via the "https" scheme have no shared + identity with the "http" scheme even if their resource identifiers + only differ by the single "s" in the scheme name. They are different + services governed by different authorities. However, some extensions + to HTTP that apply to entire host domains, such as the Cookie + protocol, do allow one service to effect communication with the other + services based on host domain matching. + + The process for authoritative access to an "https" identified + resource is defined in [RFC2818]. + +2.6.3. http and https URI Normalization and Comparison + + Since the "http" and "https" schemes conform to the URI generic + syntax, such URIs are normalized and compared according to the + algorithm defined in [RFC3986], Section 6, using the defaults + described above for each scheme. + + If the port is equal to the default port for a scheme, the normal + form is to elide the port subcomponent. Likewise, an empty path + component is equivalent to an absolute path of "/", so the normal + form is to provide a path of "/" instead. The scheme and host are + case-insensitive and normally provided in lowercase; all other + components are compared in a case-sensitive manner. Characters other + than those in the "reserved" set are equivalent to their percent- + encoded octets (see [RFC3986], Section 2.1): the normal form is to + + + +Fielding, et al. Expires February 5, 2011 [Page 18] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + not encode them. + + For example, the following three URIs are equivalent: + + http://example.com:80/~smith/home.html + http://EXAMPLE.com/%7Esmith/home.html + http://EXAMPLE.com:/%7esmith/home.html + + [[TODO-not-here: This paragraph does not belong here. --roy]] If + path-abempty is the empty string (i.e., there is no slash "/" path + separator following the authority), then the "http" URI MUST be given + as "/" when used as a request-target (Section 4.1.2). If a proxy + receives a host name which is not a fully qualified domain name, it + MAY add its domain to the host name it received. If a proxy receives + a fully qualified domain name, the proxy MUST NOT change the host + name. + +3. HTTP Message + + All HTTP/1.1 messages consist of a start-line followed by a sequence + of characters in a format similar to the Internet Message Format + [RFC5322]: zero or more header fields (collectively referred to as + the "headers" or the "header section"), an empty line indicating the + end of the header section, and an optional message-body. + + An HTTP message can either be a request from client to server or a + response from server to client. Syntactically, the two types of + message differ only in the start-line, which is either a Request-Line + (for requests) or a Status-Line (for responses), and in the algorithm + for determining the length of the message-body (Section 3.3). In + theory, a client could receive requests and a server could receive + responses, distinguishing them by their different start-line formats, + but in practice servers are implemented to only expect a request (a + response is interpreted as an unknown or invalid request method) and + clients are implemented to only expect a response. + + HTTP-message = start-line + *( header-field CRLF ) + CRLF + [ message-body ] + start-line = Request-Line / Status-Line + + Whitespace (WSP) MUST NOT be sent between the start-line and the + first header field. The presence of whitespace might be an attempt + to trick a noncompliant implementation of HTTP into ignoring that + field or processing the next line as a new request, either of which + might result in security issues when implementations within the + request chain interpret the same message differently. HTTP/1.1 + + + +Fielding, et al. Expires February 5, 2011 [Page 19] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + servers MUST reject such a message with a 400 (Bad Request) response. + +3.1. Message Parsing Robustness + + In the interest of robustness, servers SHOULD ignore at least one + empty line received where a Request-Line is expected. In other + words, if the server is reading the protocol stream at the beginning + of a message and receives a CRLF first, it SHOULD ignore the CRLF. + + Some old HTTP/1.0 client implementations generate an extra CRLF after + a POST request as a lame workaround for some early server + applications that failed to read message-body content that was not + terminated by a line-ending. An HTTP/1.1 client MUST NOT preface or + follow a request with an extra CRLF. If terminating the request + message-body with a line-ending is desired, then the client MUST + include the terminating CRLF octets as part of the message-body + length. + + The normal procedure for parsing an HTTP message is to read the + start-line into a structure, read each header field into a hash table + by field name until the empty line, and then use the parsed data to + determine if a message-body is expected. If a message-body has been + indicated, then it is read as a stream until an amount of octets + equal to the message-body length is read or the connection is closed. + Care must be taken to parse an HTTP message as a sequence of octets + in an encoding that is a superset of US-ASCII. Attempting to parse + HTTP as a stream of Unicode characters in a character encoding like + UTF-16 might introduce security flaws due to the differing ways that + such parsers interpret invalid characters. + + HTTP allows the set of defined header fields to be extended without + changing the protocol version (see Section 10.1). However, such + fields might not be recognized by a downstream recipient and might be + stripped by non-transparent intermediaries. Unrecognized header + fields MUST be forwarded by transparent proxies and SHOULD be ignored + by a recipient. + +3.2. Header Fields + + Each HTTP header field consists of a case-insensitive field name + followed by a colon (":"), optional whitespace, and the field value. + + header-field = field-name ":" OWS [ field-value ] OWS + field-name = token + field-value = *( field-content / OWS ) + field-content = *( WSP / VCHAR / obs-text ) + + No whitespace is allowed between the header field name and colon. + + + +Fielding, et al. Expires February 5, 2011 [Page 20] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + For security reasons, any request message received containing such + whitespace MUST be rejected with a response code of 400 (Bad + Request). A proxy MUST remove any such whitespace from a response + message before forwarding the message downstream. + + A field value MAY be preceded by optional whitespace (OWS); a single + SP is preferred. The field value does not include any leading or + trailing white space: OWS occurring before the first non-whitespace + character of the field value or after the last non-whitespace + character of the field value is ignored and SHOULD be removed before + further processing (as this does not change the meaning of the header + field). + + The order in which header fields with differing field names are + received is not significant. However, it is "good practice" to send + header fields that contain control data first, such as Host on + requests and Date on responses, so that implementations can decide + when not to handle a message as early as possible. A server MUST + wait until the entire header section is received before interpreting + a request message, since later header fields might include + conditionals, authentication credentials, or deliberately misleading + duplicate header fields that would impact request processing. + + Multiple header fields with the same field name MUST NOT be sent in a + message unless the entire field value for that header field is + defined as a comma-separated list [i.e., #(values)]. Multiple header + fields with the same field name can be combined into one "field-name: + field-value" pair, without changing the semantics of the message, by + appending each subsequent field value to the combined field value in + order, separated by a comma. The order in which header fields with + the same field name are received is therefore significant to the + interpretation of the combined field value; a proxy MUST NOT change + the order of these field values when forwarding a message. + + Note: The "Set-Cookie" header as implemented in practice (as + opposed to how it is specified in [RFC2109]) can occur multiple + times, but does not use the list syntax, and thus cannot be + combined into a single line. (See Appendix A.2.3 of [Kri2001] for + details.) Also note that the Set-Cookie2 header specified in + [RFC2965] does not share this problem. + + Historically, HTTP header field values could be extended over + multiple lines by preceding each extra line with at least one space + or horizontal tab character (line folding). This specification + deprecates such line folding except within the message/http media + type (Section 10.3.1). HTTP/1.1 senders MUST NOT produce messages + that include line folding (i.e., that contain any field-content that + matches the obs-fold rule) unless the message is intended for + + + +Fielding, et al. Expires February 5, 2011 [Page 21] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + packaging within the message/http media type. HTTP/1.1 recipients + SHOULD accept line folding and replace any embedded obs-fold + whitespace with a single SP prior to interpreting the field value or + forwarding the message downstream. + + Historically, HTTP has allowed field content with text in the ISO- + 8859-1 [ISO-8859-1] character encoding and supported other character + sets only through use of [RFC2047] encoding. In practice, most HTTP + header field values use only a subset of the US-ASCII character + encoding [USASCII]. Newly defined header fields SHOULD limit their + field values to US-ASCII characters. Recipients SHOULD treat other + (obs-text) octets in field content as opaque data. + + 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. + + comment = "(" *( ctext / quoted-cpair / comment ) ")" + ctext = OWS / %x21-27 / %x2A-5B / %x5D-7E / obs-text + ; OWS / <VCHAR except "(", ")", and "\"> / obs-text + + The backslash character ("\") can be used as a single-character + quoting mechanism within comment constructs: + + quoted-cpair = "\" ( WSP / VCHAR / obs-text ) + + Producers SHOULD NOT escape characters that do not require escaping + (i.e., other than the backslash character "\" and the parentheses "(" + and ")"). + +3.3. Message Body + + The message-body (if any) of an HTTP message is used to carry the + payload body associated with the request or response. + + message-body = *OCTET + + The message-body differs from the payload body only when a transfer- + coding has been applied, as indicated by the Transfer-Encoding header + field (Section 9.7). When one or more transfer-codings are applied + to a payload in order to form the message-body, the Transfer-Encoding + header field MUST contain the list of transfer-codings applied. + Transfer-Encoding is a property of the message, not of the payload, + and thus MAY be added or removed by any implementation along the + request/response chain under the constraints found in Section 6.2. + + The rules for when a message-body is allowed in a message differ for + requests and responses. + + + +Fielding, et al. Expires February 5, 2011 [Page 22] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + The presence of a message-body in a request is signaled by the + inclusion of a Content-Length or Transfer-Encoding header field in + the request's header fields, even if the request method does not + define any use for a message-body. This allows the request message + framing algorithm to be independent of method semantics. + + For response messages, whether or not a message-body is included with + a message is dependent on both the request method and the response + status code (Section 5.1.1). Responses to the HEAD request method + never include a message-body because the associated response header + fields (e.g., Transfer-Encoding, Content-Length, etc.) only indicate + what their values would have been if the method had been GET. All + 1xx (Informational), 204 (No Content), and 304 (Not Modified) + responses MUST NOT include a message-body. All other responses do + include a message-body, although the body MAY be of zero length. + + The length of the message-body is determined by one of the following + (in order of precedence): + + 1. Any response to a HEAD request and any response with a status + code of 100-199, 204, or 304 is always terminated by the first + empty line after the header fields, regardless of the header + fields present in the message, and thus cannot contain a message- + body. + + 2. If a Transfer-Encoding header field (Section 9.7) is present and + the "chunked" transfer-coding (Section 6.2) is the final + encoding, the message-body length is determined by reading and + decoding the chunked data until the transfer-coding indicates the + data is complete. + + If a Transfer-Encoding header field is present in a response and + the "chunked" transfer-coding is not the final encoding, the + message-body length is determined by reading the connection until + it is closed by the server. If a Transfer-Encoding header field + is present in a request and the "chunked" transfer-coding is not + the final encoding, the message-body length cannot be determined + reliably; the server MUST respond with the 400 (Bad Request) + status code and then close the connection. + + If a message is received with both a Transfer-Encoding header + field and a Content-Length header field, the Transfer-Encoding + overrides the Content-Length. Such a message might indicate an + attempt to perform request or response smuggling (bypass of + security-related checks on message routing or content) and thus + ought to be handled as an error. The provided Content-Length + MUST be removed, prior to forwarding the message downstream, or + replaced with the real message-body length after the transfer- + + + +Fielding, et al. Expires February 5, 2011 [Page 23] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + coding is decoded. + + 3. If a message is received without Transfer-Encoding and with + either multiple Content-Length header fields or a single Content- + Length header field with an invalid value, then the message + framing is invalid and MUST be treated as an error to prevent + request or response smuggling. If this is a request message, the + server MUST respond with a 400 (Bad Request) status code and then + close the connection. If this is a response message received by + a proxy or gateway, the proxy or gateway MUST discard the + received response, send a 502 (Bad Gateway) status code as its + downstream response, and then close the connection. If this is a + response message received by a user-agent, the message-body + length is determined by reading the connection until it is + closed; an error SHOULD be indicated to the user. + + 4. If a valid Content-Length header field (Section 9.2) is present + without Transfer-Encoding, its decimal value defines the message- + body length in octets. If the actual number of octets sent in + the message is less than the indicated Content-Length, the + recipient MUST consider the message to be incomplete and treat + the connection as no longer usable. If the actual number of + octets sent in the message is more than the indicated Content- + Length, the recipient MUST only process the message-body up to + the field value's number of octets; the remainder of the message + MUST either be discarded or treated as the next message in a + pipeline. For the sake of robustness, a user-agent MAY attempt + to detect and correct such an error in message framing if it is + parsing the response to the last request on on a connection and + the connection has been closed by the server. + + 5. If this is a request message and none of the above are true, then + the message-body length is zero (no message-body is present). + + 6. Otherwise, this is a response message without a declared message- + body length, so the message-body length is determined by the + number of octets received prior to the server closing the + connection. + + Since there is no way to distinguish a successfully completed, close- + delimited message from a partially-received message interrupted by + network failure, implementations SHOULD use encoding or length- + delimited messages whenever possible. The close-delimiting feature + exists primarily for backwards compatibility with HTTP/1.0. + + A server MAY reject a request that contains a message-body but not a + Content-Length by responding with 411 (Length Required). + + + + +Fielding, et al. Expires February 5, 2011 [Page 24] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + Unless a transfer-coding other than "chunked" has been applied, a + client that sends a request containing a message-body SHOULD use a + valid Content-Length header field if the message-body length is known + in advance, rather than the "chunked" encoding, since some existing + services respond to "chunked" with a 411 (Length Required) status + code even though they understand the chunked encoding. This is + typically because such services are implemented via a gateway that + requires a content-length in advance of being called and the server + is unable or unwilling to buffer the entire request before + processing. + + A client that sends a request containing a message-body MUST include + a valid Content-Length header field if it does not know the server + will handle HTTP/1.1 (or later) requests; such knowledge can be in + the form of specific user configuration or by remembering the version + of a prior received response. + + Request messages that are prematurely terminated, possibly due to a + cancelled connection or a server-imposed time-out exception, MUST + result in closure of the connection; sending an HTTP/1.1 error + response prior to closing the connection is OPTIONAL. Response + messages that are prematurely terminated, usually by closure of the + connection prior to receiving the expected number of octets or by + failure to decode a transfer-encoded message-body, MUST be recorded + as incomplete. A user agent MUST NOT render an incomplete response + message-body as if it were complete (i.e., some indication must be + given to the user that an error occurred). Cache requirements for + incomplete responses are defined in Section 2.1.1 of [Part6]. + + A server MUST read the entire request message-body or close the + connection after sending its response, since otherwise the remaining + data on a persistent connection would be misinterpreted as the next + request. Likewise, a client MUST read the entire response message- + body if it intends to reuse the same connection for a subsequent + request. Pipelining multiple requests on a connection is described + in Section 7.1.2.2. + +3.4. General Header Fields + + There are a few header fields which have general applicability for + both request and response messages, but which do not apply to the + payload being transferred. These header fields apply only to the + message being transmitted. + + + + + + + + +Fielding, et al. Expires February 5, 2011 [Page 25] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + general-header = Cache-Control ; [Part6], Section 3.2 + / Connection ; Section 9.1 + / Date ; Section 9.3 + / Pragma ; [Part6], Section 3.4 + / Trailer ; Section 9.6 + / Transfer-Encoding ; Section 9.7 + / Upgrade ; Section 9.8 + / Via ; Section 9.9 + / Warning ; [Part6], Section 3.6 + / MIME-Version ; [Part3], Appendix A.1 + + General-header field names can be extended reliably only in + combination with a change in the protocol version. However, new or + experimental header fields might be given the semantics of general + header fields if all parties in the communication recognize them to + be general-header fields. + +4. Request + + A request message from a client to a server includes, within the + first line of that message, the method to be applied to the resource, + the identifier of the resource, and the protocol version in use. + + Request = Request-Line ; Section 4.1 + *( header-field CRLF ) ; Section 3.2 + CRLF + [ message-body ] ; Section 3.3 + +4.1. Request-Line + + The Request-Line begins with a method token, followed by the request- + target and the protocol version, and ending with CRLF. The elements + are separated by SP characters. No CR or LF is allowed except in the + final CRLF sequence. + + Request-Line = Method SP request-target SP HTTP-Version CRLF + +4.1.1. Method + + The Method token indicates the method to be performed on the resource + identified by the request-target. The method is case-sensitive. + + Method = token + + + + + + + + +Fielding, et al. Expires February 5, 2011 [Page 26] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + +4.1.2. request-target + + The request-target identifies the resource upon which to apply the + request. + + request-target = "*" + / absolute-URI + / ( path-absolute [ "?" query ] ) + / authority + + The four options for request-target are dependent on the nature of + the request. + + The asterisk "*" means that the request does not apply to a + particular resource, but to the server itself, and is only allowed + when the method used does not necessarily apply to a resource. One + example would be + + OPTIONS * HTTP/1.1 + + The absolute-URI form is REQUIRED when the request is being made to a + proxy. The proxy is requested to forward the request or service it + from a valid cache, and return the response. Note that the proxy MAY + forward the request on to another proxy or directly to the server + specified by the absolute-URI. In order to avoid request loops, a + proxy MUST be able to recognize all of its server names, including + any aliases, local variations, and the numeric IP address. An + example Request-Line would be: + + GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1 + + To allow for transition to absolute-URIs in all requests in future + versions of HTTP, all HTTP/1.1 servers MUST accept the absolute-URI + form in requests, even though HTTP/1.1 clients will only generate + them in requests to proxies. + + The authority form is only used by the CONNECT method (Section 7.9 of + [Part2]). + + The most common form of request-target is that used to identify a + resource on an origin server or gateway. In this case the absolute + path of the URI MUST be transmitted (see Section 2.6.1, path- + absolute) as the request-target, and the network location of the URI + (authority) MUST be transmitted in a Host header field. For example, + a client wishing to retrieve the resource above directly from the + origin server would create a TCP connection to port 80 of the host + "www.example.org" and send the lines: + + + + +Fielding, et al. Expires February 5, 2011 [Page 27] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + GET /pub/WWW/TheProject.html HTTP/1.1 + Host: www.example.org + + followed by the remainder of the Request. Note that the absolute + path cannot be empty; if none is present in the original URI, it MUST + be given as "/" (the server root). + + If a proxy receives a request without any path in the request-target + and the method specified is capable of supporting the asterisk form + of request-target, then the last proxy on the request chain MUST + forward the request with "*" as the final request-target. + + For example, the request + + OPTIONS http://www.example.org:8001 HTTP/1.1 + + would be forwarded by the proxy as + + OPTIONS * HTTP/1.1 + Host: www.example.org:8001 + + after connecting to port 8001 of host "www.example.org". + + The request-target is transmitted in the format specified in + Section 2.6.1. If the request-target is percent-encoded ([RFC3986], + Section 2.1), the origin server MUST decode the request-target in + order to properly interpret the request. Servers SHOULD respond to + invalid request-targets with an appropriate status code. + + A transparent proxy MUST NOT rewrite the "path-absolute" part of the + received request-target when forwarding it to the next inbound + server, except as noted above to replace a null path-absolute with + "/" or "*". + + Note: The "no rewrite" rule prevents the proxy from changing the + meaning of the request when the origin server is improperly using + a non-reserved URI character for a reserved purpose. Implementors + need to be aware that some pre-HTTP/1.1 proxies have been known to + rewrite the request-target. + + HTTP does not place a pre-defined limit on the length of a request- + target. A server MUST be prepared to receive URIs of unbounded + length and respond with the 414 (URI Too Long) status code if the + received request-target would be longer than the server wishes to + handle (see Section 8.4.15 of [Part2]). + + Various ad-hoc limitations on request-target length are found in + practice. It is RECOMMENDED that all HTTP senders and recipients + + + +Fielding, et al. Expires February 5, 2011 [Page 28] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + support request-target lengths of 8000 or more octets. + + Note: Fragments ([RFC3986], Section 3.5) are not part of the + request-target and thus will not be transmitted in an HTTP + request. + +4.2. The Resource Identified by a Request + + The exact resource identified by an Internet request is determined by + examining both the request-target and the Host header field. + + An origin server that does not allow resources to differ by the + requested host MAY ignore the Host header field value when + determining the resource identified by an HTTP/1.1 request. (But see + Appendix B.1.1 for other requirements on Host support in HTTP/1.1.) + + An origin server that does differentiate resources based on the host + requested (sometimes referred to as virtual hosts or vanity host + names) MUST use the following rules for determining the requested + resource on an HTTP/1.1 request: + + 1. If request-target is an absolute-URI, the host is part of the + request-target. Any Host header field value in the request MUST + be ignored. + + 2. If the request-target is not an absolute-URI, and the request + includes a Host header field, the host is determined by the Host + header field value. + + 3. If the host as determined by rule 1 or 2 is not a valid host on + the server, the response MUST be a 400 (Bad Request) error + message. + + Recipients of an HTTP/1.0 request that lacks a Host header field MAY + attempt to use heuristics (e.g., examination of the URI path for + something unique to a particular host) in order to determine what + exact resource is being requested. + +4.3. Effective Request URI + + HTTP requests often do not carry the absolute URI ([RFC3986], Section + 4.3) for the target resource; instead, the URI needs to be inferred + from the request-target, Host header field, and connection context. + The result of this process is called the "effective request URI". + The "target resource" is the resource identified by the effective + request URI. + + If the request-target is an absolute-URI, then the effective request + + + +Fielding, et al. Expires February 5, 2011 [Page 29] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + URI is the request-target. + + If the request-target uses the path-absolute (plus optional query) + syntax or if it is just the asterisk "*", then the effective request + URI is constructed by concatenating + + o the scheme name: "http" if the request was received over an + insecure TCP connection, or "https" when received over a SSL/ + TLS-secured TCP connection, + + o the character sequence "://", + + o the authority component, as specified in the Host header + (Section 9.4) and determined by the rules in Section 4.2, + [[effrequri-nohost: Do we need to include the handling of missing + hosts in HTTP/1.0 messages, as described in Section 4.2? -- See + <http://tools.ietf.org/wg/httpbis/trac/ticket/221> --jre]] and + + o the request-target obtained from the Request-Line, unless the + request-target is just the asterisk "*". + + Otherwise, when request-target uses the authority form, the effective + Request URI is undefined. + + Example 1: the effective request URI for the message + + GET /pub/WWW/TheProject.html HTTP/1.1 + Host: www.example.org:8080 + + (received over an insecure TCP connection) is "http", plus "://", + plus the authority component "www.example.org:8080", plus the + request-target "/pub/WWW/TheProject.html", thus + "http://www.example.org:8080/pub/WWW/TheProject.html". + + Example 2: the effective request URI for the message + + GET * HTTP/1.1 + Host: www.example.org + + (received over an SSL/TLS secured TCP connection) is "https", plus + "://", plus the authority component "www.example.org", thus + "https://www.example.org". + + Effective request URIs are compared using the rules described in + Section 2.6.3, except that empty path components MUST NOT be treated + as equivalent to an absolute path of "/". + + + + + +Fielding, et al. Expires February 5, 2011 [Page 30] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + +5. Response + + After receiving and interpreting a request message, a server responds + with an HTTP response message. + + Response = Status-Line ; Section 5.1 + *( header-field CRLF ) ; Section 3.2 + CRLF + [ message-body ] ; Section 3.3 + +5.1. Status-Line + + The first line of a Response message is the Status-Line, consisting + of the protocol version followed by a numeric status code and its + associated textual phrase, with each element separated by SP + characters. No CR or LF is allowed except in the final CRLF + sequence. + + Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF + +5.1.1. Status Code and Reason Phrase + + The Status-Code element is a 3-digit integer result code of the + attempt to understand and satisfy the request. These codes are fully + defined in Section 8 of [Part2]. The Reason Phrase exists for the + sole purpose of providing a textual description associated with the + numeric status code, out of deference to earlier Internet application + protocols that were more frequently used with interactive text + clients. A client SHOULD ignore the content of the Reason Phrase. + + The first digit of the Status-Code defines the class of response. + The last two digits do not have any categorization role. There are 5 + values for the first digit: + + o 1xx: Informational - Request received, continuing process + + o 2xx: Success - The action was successfully received, understood, + and accepted + + o 3xx: Redirection - Further action must be taken in order to + complete the request + + o 4xx: Client Error - The request contains bad syntax or cannot be + fulfilled + + o 5xx: Server Error - The server failed to fulfill an apparently + valid request + + + + +Fielding, et al. Expires February 5, 2011 [Page 31] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + Status-Code = 3DIGIT + Reason-Phrase = *( WSP / VCHAR / obs-text ) + +6. Protocol Parameters + +6.1. Date/Time Formats: Full Date + + HTTP applications have historically allowed three different formats + for date/time stamps. However, the preferred format is a fixed- + length subset of that defined by [RFC1123]: + + Sun, 06 Nov 1994 08:49:37 GMT ; RFC 1123 + + The other formats are described here only for compatibility with + obsolete implementations. + + Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format + Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format + + HTTP/1.1 clients and servers that parse a date value MUST accept all + three formats (for compatibility with HTTP/1.0), though they MUST + only generate the RFC 1123 format for representing HTTP-date values + in header fields. See Appendix A for further information. + + All HTTP date/time stamps MUST be represented in Greenwich Mean Time + (GMT), without exception. For the purposes of HTTP, GMT is exactly + equal to UTC (Coordinated Universal Time). This is indicated in the + first two formats by the inclusion of "GMT" as the three-letter + abbreviation for time zone, and MUST be assumed when reading the + asctime format. HTTP-date is case sensitive and MUST NOT include + additional whitespace beyond that specifically included as SP in the + grammar. + + HTTP-date = rfc1123-date / obs-date + + Preferred format: + + + + + + + + + + + + + + + +Fielding, et al. Expires February 5, 2011 [Page 32] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT + + day-name = %x4D.6F.6E ; "Mon", case-sensitive + / %x54.75.65 ; "Tue", case-sensitive + / %x57.65.64 ; "Wed", case-sensitive + / %x54.68.75 ; "Thu", case-sensitive + / %x46.72.69 ; "Fri", case-sensitive + / %x53.61.74 ; "Sat", case-sensitive + / %x53.75.6E ; "Sun", case-sensitive + + date1 = day SP month SP year + ; e.g., 02 Jun 1982 + + day = 2DIGIT + month = %x4A.61.6E ; "Jan", case-sensitive + / %x46.65.62 ; "Feb", case-sensitive + / %x4D.61.72 ; "Mar", case-sensitive + / %x41.70.72 ; "Apr", case-sensitive + / %x4D.61.79 ; "May", case-sensitive + / %x4A.75.6E ; "Jun", case-sensitive + / %x4A.75.6C ; "Jul", case-sensitive + / %x41.75.67 ; "Aug", case-sensitive + / %x53.65.70 ; "Sep", case-sensitive + / %x4F.63.74 ; "Oct", case-sensitive + / %x4E.6F.76 ; "Nov", case-sensitive + / %x44.65.63 ; "Dec", case-sensitive + year = 4DIGIT + + GMT = %x47.4D.54 ; "GMT", case-sensitive + + time-of-day = hour ":" minute ":" second + ; 00:00:00 - 23:59:59 + + hour = 2DIGIT + minute = 2DIGIT + second = 2DIGIT + + The semantics of day-name, day, month, year, and time-of-day are the + same as those defined for the RFC 5322 constructs with the + corresponding name ([RFC5322], Section 3.3). + + Obsolete formats: + + obs-date = rfc850-date / asctime-date + + + + + + + +Fielding, et al. Expires February 5, 2011 [Page 33] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT + date2 = day "-" month "-" 2DIGIT + ; day-month-year (e.g., 02-Jun-82) + + day-name-l = %x4D.6F.6E.64.61.79 ; "Monday", case-sensitive + / %x54.75.65.73.64.61.79 ; "Tuesday", case-sensitive + / %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive + / %x54.68.75.72.73.64.61.79 ; "Thursday", case-sensitive + / %x46.72.69.64.61.79 ; "Friday", case-sensitive + / %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive + / %x53.75.6E.64.61.79 ; "Sunday", case-sensitive + + + asctime-date = day-name SP date3 SP time-of-day SP year + date3 = month SP ( 2DIGIT / ( SP 1DIGIT )) + ; month day (e.g., Jun 2) + + Note: Recipients of date values are encouraged to be robust in + accepting date values that might have been sent by non-HTTP + applications, as is sometimes the case when retrieving or posting + messages via proxies/gateways to SMTP or NNTP. + + Note: HTTP requirements for the date/time stamp format apply only + to their usage within the protocol stream. Clients and servers + are not required to use these formats for user presentation, + request logging, etc. + +6.2. Transfer Codings + + Transfer-coding values are used to indicate an encoding + transformation that has been, can be, or might need to be applied to + a payload body in order to ensure "safe transport" through the + network. This differs from a content coding in that the transfer- + coding is a property of the message rather than a property of the + representation that is being transferred. + + transfer-coding = "chunked" ; Section 6.2.1 + / "compress" ; Section 6.2.2.1 + / "deflate" ; Section 6.2.2.2 + / "gzip" ; Section 6.2.2.3 + / transfer-extension + transfer-extension = token *( OWS ";" OWS transfer-parameter ) + + Parameters are in the form of attribute/value pairs. + + transfer-parameter = attribute BWS "=" BWS value + attribute = token + value = word + + + +Fielding, et al. Expires February 5, 2011 [Page 34] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + All transfer-coding values are case-insensitive. HTTP/1.1 uses + transfer-coding values in the TE header field (Section 9.5) and in + the Transfer-Encoding header field (Section 9.7). + + Transfer-codings are analogous to the Content-Transfer-Encoding + values of MIME, which were designed to enable safe transport of + binary data over a 7-bit transport service ([RFC2045], Section 6). + However, safe transport has a different focus for an 8bit-clean + transfer protocol. In HTTP, the only unsafe characteristic of + message-bodies is the difficulty in determining the exact message + body length (Section 3.3), or the desire to encrypt data over a + shared transport. + + A server that receives a request message with a transfer-coding it + does not understand SHOULD respond with 501 (Not Implemented) and + then close the connection. A server MUST NOT send transfer-codings + to an HTTP/1.0 client. + +6.2.1. Chunked Transfer Coding + + The chunked encoding modifies the body of a message in order to + transfer it as a series of chunks, each with its own size indicator, + followed by an OPTIONAL trailer containing header fields. This + allows dynamically produced content to be transferred along with the + information necessary for the recipient to verify that it has + received the full message. + + Chunked-Body = *chunk + last-chunk + trailer-part + CRLF + + chunk = chunk-size *WSP [ chunk-ext ] CRLF + chunk-data CRLF + chunk-size = 1*HEXDIG + last-chunk = 1*("0") *WSP [ chunk-ext ] CRLF + + chunk-ext = *( ";" *WSP chunk-ext-name + [ "=" chunk-ext-val ] *WSP ) + chunk-ext-name = token + chunk-ext-val = token / quoted-str-nf + chunk-data = 1*OCTET ; a sequence of chunk-size octets + trailer-part = *( header-field CRLF ) + + quoted-str-nf = DQUOTE *( qdtext-nf / quoted-pair ) DQUOTE + ; like quoted-string, but disallowing line folding + qdtext-nf = WSP / %x21 / %x23-5B / %x5D-7E / obs-text + ; WSP / <VCHAR except DQUOTE and "\"> / obs-text + + + +Fielding, et al. Expires February 5, 2011 [Page 35] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + The chunk-size field is a string of hex digits indicating the size of + the chunk-data in octets. The chunked encoding is ended by any chunk + whose size is zero, followed by the trailer, which is terminated by + an empty line. + + The trailer allows the sender to include additional HTTP header + fields at the end of the message. The Trailer header field can be + used to indicate which header fields are included in a trailer (see + Section 9.6). + + A server using chunked transfer-coding in a response MUST NOT use the + trailer for any header fields unless at least one of the following is + true: + + 1. the request included a TE header field that indicates "trailers" + is acceptable in the transfer-coding of the response, as + described in Section 9.5; or, + + 2. the server is the origin server for the response, the trailer + fields consist entirely of optional metadata, and the recipient + could use the message (in a manner acceptable to the origin + server) without receiving this metadata. In other words, the + origin server is willing to accept the possibility that the + trailer fields might be silently discarded along the path to the + client. + + This requirement prevents an interoperability failure when the + message is being received by an HTTP/1.1 (or later) proxy and + forwarded to an HTTP/1.0 recipient. It avoids a situation where + compliance with the protocol would have necessitated a possibly + infinite buffer on the proxy. + + A process for decoding the "chunked" transfer-coding can be + represented in pseudo-code as: + + + + + + + + + + + + + + + + + +Fielding, et al. Expires February 5, 2011 [Page 36] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + length := 0 + read chunk-size, chunk-ext (if any) and CRLF + while (chunk-size > 0) { + read chunk-data and CRLF + append chunk-data to decoded-body + length := length + chunk-size + read chunk-size and CRLF + } + read header-field + while (header-field not empty) { + append header-field to existing header fields + read header-field + } + Content-Length := length + Remove "chunked" from Transfer-Encoding + + All HTTP/1.1 applications MUST be able to receive and decode the + "chunked" transfer-coding and MUST ignore chunk-ext extensions they + do not understand. + + Since "chunked" is the only transfer-coding required to be understood + by HTTP/1.1 recipients, it plays a crucial role in delimiting + messages on a persistent connection. Whenever a transfer-coding is + applied to a payload body in a request, the final transfer-coding + applied MUST be "chunked". If a transfer-coding is applied to a + response payload body, then either the final transfer-coding applied + MUST be "chunked" or the message MUST be terminated by closing the + connection. When the "chunked" transfer-coding is used, it MUST be + the last transfer-coding applied to form the message-body. The + "chunked" transfer-coding MUST NOT be applied more than once in a + message-body. + +6.2.2. Compression Codings + + The codings defined below can be used to compress the payload of a + message. + + Note: Use of program names for the identification of encoding + formats is not desirable and is discouraged for future encodings. + Their use here is representative of historical practice, not good + design. + + Note: For compatibility with previous implementations of HTTP, + applications SHOULD consider "x-gzip" and "x-compress" to be + equivalent to "gzip" and "compress" respectively. + + + + + + +Fielding, et al. Expires February 5, 2011 [Page 37] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + +6.2.2.1. Compress Coding + + The "compress" format is produced by the common UNIX file compression + program "compress". This format is an adaptive Lempel-Ziv-Welch + coding (LZW). + +6.2.2.2. Deflate Coding + + The "deflate" format is defined as the "deflate" compression + mechanism (described in [RFC1951]) used inside the "zlib" data format + ([RFC1950]). + + Note: Some incorrect implementations send the "deflate" compressed + data without the zlib wrapper. + +6.2.2.3. Gzip Coding + + The "gzip" format is produced by the file compression program "gzip" + (GNU zip), as described in [RFC1952]. This format is a Lempel-Ziv + coding (LZ77) with a 32 bit CRC. + +6.2.3. Transfer Coding Registry + + The HTTP Transfer Coding Registry defines the name space for the + transfer coding names. + + Registrations MUST include the following fields: + + o Name + + o Description + + o Pointer to specification text + + Names of transfer codings MUST NOT overlap with names of content + codings (Section 2.2 of [Part3]), unless the encoding transformation + is identical (as it is the case for the compression codings defined + in Section 6.2.2). + + Values to be added to this name space require a specification (see + "Specification Required" in Section 4.1 of [RFC5226]), and MUST + conform to the purpose of transfer coding defined in this section. + + The registry itself is maintained at + <http://www.iana.org/assignments/http-parameters>. + + + + + + +Fielding, et al. Expires February 5, 2011 [Page 38] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + +6.3. Product Tokens + + Product tokens are used to allow communicating applications to + identify themselves by software name and version. Most fields using + product tokens also allow sub-products which form a significant part + of the application to be listed, separated by whitespace. By + convention, the products are listed in order of their significance + for identifying the application. + + product = token ["/" product-version] + product-version = token + + Examples: + + User-Agent: CERN-LineMode/2.15 libwww/2.17b3 + Server: Apache/0.8.4 + + Product tokens SHOULD be short and to the point. They MUST NOT be + used for advertising or other non-essential information. Although + any token character MAY appear in a product-version, this token + SHOULD only be used for a version identifier (i.e., successive + versions of the same product SHOULD only differ in the product- + version portion of the product value). + +6.4. Quality Values + + Both transfer codings (TE request header, Section 9.5) and content + negotiation (Section 5 of [Part3]) use short "floating point" numbers + to indicate the relative importance ("weight") of various negotiable + parameters. A weight is normalized to a real number in the range 0 + through 1, where 0 is the minimum and 1 the maximum value. If a + parameter has a quality value of 0, then content with this parameter + is "not acceptable" for the client. HTTP/1.1 applications MUST NOT + generate more than three digits after the decimal point. User + configuration of these values SHOULD also be limited in this fashion. + + qvalue = ( "0" [ "." 0*3DIGIT ] ) + / ( "1" [ "." 0*3("0") ] ) + + Note: "Quality values" is a misnomer, since these values merely + represent relative degradation in desired quality. + +7. Connections + +7.1. Persistent Connections + + + + + + +Fielding, et al. Expires February 5, 2011 [Page 39] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + +7.1.1. Purpose + + Prior to persistent connections, a separate TCP connection was + established to fetch each URL, increasing the load on HTTP servers + and causing congestion on the Internet. The use of inline images and + other associated data often requires a client to make multiple + requests of the same server in a short amount of time. Analysis of + these performance problems and results from a prototype + implementation are available [Pad1995] [Spe]. Implementation + experience and measurements of actual HTTP/1.1 implementations show + good results [Nie1997]. Alternatives have also been explored, for + example, T/TCP [Tou1998]. + + Persistent HTTP connections have a number of advantages: + + o By opening and closing fewer TCP connections, CPU time is saved in + routers and hosts (clients, servers, proxies, gateways, tunnels, + or caches), and memory used for TCP protocol control blocks can be + saved in hosts. + + o HTTP requests and responses can be pipelined on a connection. + Pipelining allows a client to make multiple requests without + waiting for each response, allowing a single TCP connection to be + used much more efficiently, with much lower elapsed time. + + o Network congestion is reduced by reducing the number of packets + caused by TCP opens, and by allowing TCP sufficient time to + determine the congestion state of the network. + + o Latency on subsequent requests is reduced since there is no time + spent in TCP's connection opening handshake. + + o HTTP can evolve more gracefully, since errors can be reported + without the penalty of closing the TCP connection. Clients using + future versions of HTTP might optimistically try a new feature, + but if communicating with an older server, retry with old + semantics after an error is reported. + + HTTP implementations SHOULD implement persistent connections. + +7.1.2. Overall Operation + + A significant difference between HTTP/1.1 and earlier versions of + HTTP is that persistent connections are the default behavior of any + HTTP connection. That is, unless otherwise indicated, the client + SHOULD assume that the server will maintain a persistent connection, + even after error responses from the server. + + + + +Fielding, et al. Expires February 5, 2011 [Page 40] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + Persistent connections provide a mechanism by which a client and a + server can signal the close of a TCP connection. This signaling + takes place using the Connection header field (Section 9.1). Once a + close has been signaled, the client MUST NOT send any more requests + on that connection. + +7.1.2.1. Negotiation + + An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to + maintain a persistent connection unless a Connection header including + the connection-token "close" was sent in the request. If the server + chooses to close the connection immediately after sending the + response, it SHOULD send a Connection header including the + connection-token "close". + + An HTTP/1.1 client MAY expect a connection to remain open, but would + decide to keep it open based on whether the response from a server + contains a Connection header with the connection-token close. In + case the client does not want to maintain a connection for more than + that request, it SHOULD send a Connection header including the + connection-token close. + + If either the client or the server sends the close token in the + Connection header, that request becomes the last one for the + connection. + + Clients and servers SHOULD NOT assume that a persistent connection is + maintained for HTTP versions less than 1.1 unless it is explicitly + signaled. See Appendix B.2 for more information on backward + compatibility with HTTP/1.0 clients. + + In order to remain persistent, all messages on the connection MUST + have a self-defined message length (i.e., one not defined by closure + of the connection), as described in Section 3.3. + +7.1.2.2. Pipelining + + A client that supports persistent connections MAY "pipeline" its + requests (i.e., send multiple requests without waiting for each + response). A server MUST send its responses to those requests in the + same order that the requests were received. + + Clients which assume persistent connections and pipeline immediately + after connection establishment SHOULD be prepared to retry their + connection if the first pipelined attempt fails. If a client does + such a retry, it MUST NOT pipeline before it knows the connection is + persistent. Clients MUST also be prepared to resend their requests + if the server closes the connection before sending all of the + + + +Fielding, et al. Expires February 5, 2011 [Page 41] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + corresponding responses. + + Clients SHOULD NOT pipeline requests using non-idempotent methods or + non-idempotent sequences of methods (see Section 7.1.2 of [Part2]). + Otherwise, a premature termination of the transport connection could + lead to indeterminate results. A client wishing to send a non- + idempotent request SHOULD wait to send that request until it has + received the response status line for the previous request. + +7.1.3. Proxy Servers + + It is especially important that proxies correctly implement the + properties of the Connection header field as specified in + Section 9.1. + + The proxy server MUST signal persistent connections separately with + its clients and the origin servers (or other proxy servers) that it + connects to. Each persistent connection applies to only one + transport link. + + A proxy server MUST NOT establish a HTTP/1.1 persistent connection + with an HTTP/1.0 client (but see Section 19.7.1 of [RFC2068] for + information and discussion of the problems with the Keep-Alive header + implemented by many HTTP/1.0 clients). + +7.1.3.1. End-to-end and Hop-by-hop Headers + + For the purpose of defining the behavior of caches and non-caching + proxies, we divide HTTP headers into two categories: + + o End-to-end headers, which are transmitted to the ultimate + recipient of a request or response. End-to-end headers in + responses MUST be stored as part of a cache entry and MUST be + transmitted in any response formed from a cache entry. + + o Hop-by-hop headers, which are meaningful only for a single + transport-level connection, and are not stored by caches or + forwarded by proxies. + + The following HTTP/1.1 headers are hop-by-hop headers: + + o Connection + + o Keep-Alive + + o Proxy-Authenticate + + + + + +Fielding, et al. Expires February 5, 2011 [Page 42] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + o Proxy-Authorization + + o TE + + o Trailer + + o Transfer-Encoding + + o Upgrade + + All other headers defined by HTTP/1.1 are end-to-end headers. + + Other hop-by-hop headers MUST be listed in a Connection header + (Section 9.1). + +7.1.3.2. Non-modifiable Headers + + Some features of HTTP/1.1, such as Digest Authentication, depend on + the value of certain end-to-end headers. A transparent proxy SHOULD + NOT modify an end-to-end header unless the definition of that header + requires or specifically allows that. + + A transparent proxy MUST NOT modify any of the following fields in a + request or response, and it MUST NOT add any of these fields if not + already present: + + o Content-Location + + o Content-MD5 + + o ETag + + o Last-Modified + + A transparent proxy MUST NOT modify any of the following fields in a + response: + + o Expires + + but it MAY add any of these fields if not already present. If an + Expires header is added, it MUST be given a field-value identical to + that of the Date header in that response. + + A proxy MUST NOT modify or add any of the following fields in a + message that contains the no-transform cache-control directive, or in + any request: + + + + + +Fielding, et al. Expires February 5, 2011 [Page 43] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + o Content-Encoding + + o Content-Range + + o Content-Type + + A non-transparent proxy MAY modify or add these fields to a message + that does not include no-transform, but if it does so, it MUST add a + Warning 214 (Transformation applied) if one does not already appear + in the message (see Section 3.6 of [Part6]). + + Warning: Unnecessary modification of end-to-end headers might + cause authentication failures if stronger authentication + mechanisms are introduced in later versions of HTTP. Such + authentication mechanisms MAY rely on the values of header fields + not listed here. + + A transparent proxy MUST preserve the message payload ([Part3]), + though it MAY change the message-body through application or removal + of a transfer-coding (Section 6.2). + +7.1.4. Practical Considerations + + Servers will usually have some time-out value beyond which they will + no longer maintain an inactive connection. Proxy servers might make + this a higher value since it is likely that the client will be making + more connections through the same server. The use of persistent + connections places no requirements on the length (or existence) of + this time-out for either the client or the server. + + When a client or server wishes to time-out it SHOULD issue a graceful + close on the transport connection. Clients and servers SHOULD both + constantly watch for the other side of the transport close, and + respond to it as appropriate. If a client or server does not detect + the other side's close promptly it could cause unnecessary resource + drain on the network. + + A client, server, or proxy MAY close the transport connection at any + time. For example, a client might have started to send a new request + at the same time that the server has decided to close the "idle" + connection. From the server's point of view, the connection is being + closed while it was idle, but from the client's point of view, a + request is in progress. + + This means that clients, servers, and proxies MUST be able to recover + from asynchronous close events. Client software SHOULD reopen the + transport connection and retransmit the aborted sequence of requests + without user interaction so long as the request sequence is + + + +Fielding, et al. Expires February 5, 2011 [Page 44] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + idempotent (see Section 7.1.2 of [Part2]). Non-idempotent methods or + sequences MUST NOT be automatically retried, although user agents MAY + offer a human operator the choice of retrying the request(s). + Confirmation by user-agent software with semantic understanding of + the application MAY substitute for user confirmation. The automatic + retry SHOULD NOT be repeated if the second sequence of requests + fails. + + Servers SHOULD always respond to at least one request per connection, + if at all possible. Servers SHOULD NOT close a connection in the + middle of transmitting a response, unless a network or client failure + is suspected. + + Clients (including proxies) SHOULD limit the number of simultaneous + connections that they maintain to a given server (including proxies). + + Previous revisions of HTTP gave a specific number of connections as a + ceiling, but this was found to be impractical for many applications. + As a result, this specification does not mandate a particular maximum + number of connections, but instead encourages clients to be + conservative when opening multiple connections. + + In particular, while using multiple connections avoids the "head-of- + line blocking" problem (whereby a request that takes significant + server-side processing and/or has a large payload can block + subsequent requests on the same connection), each connection used + consumes server resources (sometimes significantly), and furthermore + using multiple connections can cause undesirable side effects in + congested networks. + + Note that servers might reject traffic that they deem abusive, + including an excessive number of connections from a client. + +7.2. Message Transmission Requirements + +7.2.1. Persistent Connections and Flow Control + + HTTP/1.1 servers SHOULD maintain persistent connections and use TCP's + flow control mechanisms to resolve temporary overloads, rather than + terminating connections with the expectation that clients will retry. + The latter technique can exacerbate network congestion. + +7.2.2. Monitoring Connections for Error Status Messages + + An HTTP/1.1 (or later) client sending a message-body SHOULD monitor + the network connection for an error status code while it is + transmitting the request. If the client sees an error status code, + it SHOULD immediately cease transmitting the body. If the body is + + + +Fielding, et al. Expires February 5, 2011 [Page 45] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + being sent using a "chunked" encoding (Section 6.2), a zero length + chunk and empty trailer MAY be used to prematurely mark the end of + the message. If the body was preceded by a Content-Length header, + the client MUST close the connection. + +7.2.3. Use of the 100 (Continue) Status + + The purpose of the 100 (Continue) status code (see Section 8.1.1 of + [Part2]) is to allow a client that is sending a request message with + a request body to determine if the origin server is willing to accept + the request (based on the request headers) before the client sends + the request body. In some cases, it might either be inappropriate or + highly inefficient for the client to send the body if the server will + reject the message without looking at the body. + + Requirements for HTTP/1.1 clients: + + o If a client will wait for a 100 (Continue) response before sending + the request body, it MUST send an Expect request-header field + (Section 9.2 of [Part2]) with the "100-continue" expectation. + + o A client MUST NOT send an Expect request-header field (Section 9.2 + of [Part2]) with the "100-continue" expectation if it does not + intend to send a request body. + + Because of the presence of older implementations, the protocol allows + ambiguous situations in which a client might send "Expect: 100- + continue" without receiving either a 417 (Expectation Failed) or a + 100 (Continue) status code. Therefore, when a client sends this + header field to an origin server (possibly via a proxy) from which it + has never seen a 100 (Continue) status code, the client SHOULD NOT + wait for an indefinite period before sending the request body. + + Requirements for HTTP/1.1 origin servers: + + o Upon receiving a request which includes an Expect request-header + field with the "100-continue" expectation, an origin server MUST + either respond with 100 (Continue) status code and continue to + read from the input stream, or respond with a final status code. + The origin server MUST NOT wait for the request body before + sending the 100 (Continue) response. If it responds with a final + status code, it MAY close the transport connection or it MAY + continue to read and discard the rest of the request. It MUST NOT + perform the requested method if it returns a final status code. + + o An origin server SHOULD NOT send a 100 (Continue) response if the + request message does not include an Expect request-header field + with the "100-continue" expectation, and MUST NOT send a 100 + + + +Fielding, et al. Expires February 5, 2011 [Page 46] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + (Continue) response if such a request comes from an HTTP/1.0 (or + earlier) client. There is an exception to this rule: for + compatibility with [RFC2068], a server MAY send a 100 (Continue) + status code in response to an HTTP/1.1 PUT or POST request that + does not include an Expect request-header field with the "100- + continue" expectation. This exception, the purpose of which is to + minimize any client processing delays associated with an + undeclared wait for 100 (Continue) status code, applies only to + HTTP/1.1 requests, and not to requests with any other HTTP-version + value. + + o An origin server MAY omit a 100 (Continue) response if it has + already received some or all of the request body for the + corresponding request. + + o An origin server that sends a 100 (Continue) response MUST + ultimately send a final status code, once the request body is + received and processed, unless it terminates the transport + connection prematurely. + + o If an origin server receives a request that does not include an + Expect request-header field with the "100-continue" expectation, + the request includes a request body, and the server responds with + a final status code before reading the entire request body from + the transport connection, then the server SHOULD NOT close the + transport connection until it has read the entire request, or + until the client closes the connection. Otherwise, the client + might not reliably receive the response message. However, this + requirement is not be construed as preventing a server from + defending itself against denial-of-service attacks, or from badly + broken client implementations. + + Requirements for HTTP/1.1 proxies: + + o If a proxy receives a request that includes an Expect request- + header field with the "100-continue" expectation, and the proxy + either knows that the next-hop server complies with HTTP/1.1 or + higher, or does not know the HTTP version of the next-hop server, + it MUST forward the request, including the Expect header field. + + o If the proxy knows that the version of the next-hop server is + HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST + respond with a 417 (Expectation Failed) status code. + + o Proxies SHOULD maintain a cache recording the HTTP version numbers + received from recently-referenced next-hop servers. + + + + + +Fielding, et al. Expires February 5, 2011 [Page 47] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + o A proxy MUST NOT forward a 100 (Continue) response if the request + message was received from an HTTP/1.0 (or earlier) client and did + not include an Expect request-header field with the "100-continue" + expectation. This requirement overrides the general rule for + forwarding of 1xx responses (see Section 8.1 of [Part2]). + +7.2.4. Client Behavior if Server Prematurely Closes Connection + + If an HTTP/1.1 client sends a request which includes a request body, + but which does not include an Expect request-header field with the + "100-continue" expectation, and if the client is not directly + connected to an HTTP/1.1 origin server, and if the client sees the + connection close before receiving a status line from the server, the + client SHOULD retry the request. If the client does retry this + request, it MAY use the following "binary exponential backoff" + algorithm to be assured of obtaining a reliable response: + + 1. Initiate a new connection to the server + + 2. Transmit the request-headers + + 3. Initialize a variable R to the estimated round-trip time to the + server (e.g., based on the time it took to establish the + connection), or to a constant value of 5 seconds if the round- + trip time is not available. + + 4. Compute T = R * (2**N), where N is the number of previous retries + of this request. + + 5. Wait either for an error response from the server, or for T + seconds (whichever comes first) + + 6. If no error response is received, after T seconds transmit the + body of the request. + + 7. If client sees that the connection is closed prematurely, repeat + from step 1 until the request is accepted, an error response is + received, or the user becomes impatient and terminates the retry + process. + + If at any point an error status code is received, the client + + o SHOULD NOT continue and + + o SHOULD close the connection if it has not completed sending the + request message. + + + + + +Fielding, et al. Expires February 5, 2011 [Page 48] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + +8. Miscellaneous notes that might disappear + +8.1. Scheme aliases considered harmful + + [[TBD-aliases-harmful: describe why aliases like webcal are + harmful.]] + +8.2. Use of HTTP for proxy communication + + [[TBD-proxy-other: Configured to use HTTP to proxy HTTP or other + protocols.]] + +8.3. Interception of HTTP for access control + + [[TBD-intercept: Interception of HTTP traffic for initiating access + control.]] + +8.4. Use of HTTP by other protocols + + [[TBD-profiles: Profiles of HTTP defined by other protocol. + Extensions of HTTP like WebDAV.]] + +8.5. Use of HTTP by media type specification + + [[TBD-hypertext: Instructions on composing HTTP requests via + hypertext formats.]] + +9. Header Field Definitions + + This section defines the syntax and semantics of HTTP/1.1 header + fields related to message framing and transport protocols. + +9.1. Connection + + The "Connection" general-header field allows the sender to specify + options that are desired for that particular connection and MUST NOT + be communicated by proxies over further connections. + + The Connection header's value has the following grammar: + + Connection = "Connection" ":" OWS Connection-v + Connection-v = 1#connection-token + connection-token = token + + HTTP/1.1 proxies MUST parse the Connection header field before a + message is forwarded and, for each connection-token in this field, + remove any header field(s) from the message with the same name as the + connection-token. Connection options are signaled by the presence of + + + +Fielding, et al. Expires February 5, 2011 [Page 49] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + a connection-token in the Connection header field, not by any + corresponding additional header field(s), since the additional header + field might not be sent if there are no parameters associated with + that connection option. + + Message headers listed in the Connection header MUST NOT include end- + to-end headers, such as Cache-Control. + + HTTP/1.1 defines the "close" connection option for the sender to + signal that the connection will be closed after completion of the + response. For example, + + Connection: close + + in either the request or the response header fields indicates that + the connection SHOULD NOT be considered "persistent" (Section 7.1) + after the current request/response is complete. + + An HTTP/1.1 client that does not support persistent connections MUST + include the "close" connection option in every request message. + + An HTTP/1.1 server that does not support persistent connections MUST + include the "close" connection option in every response message that + does not have a 1xx (Informational) status code. + + A system receiving an HTTP/1.0 (or lower-version) message that + includes a Connection header MUST, for each connection-token in this + field, remove and ignore any header field(s) from the message with + the same name as the connection-token. This protects against + mistaken forwarding of such header fields by pre-HTTP/1.1 proxies. + See Appendix B.2. + +9.2. Content-Length + + The "Content-Length" header field indicates the size of the message- + body, in decimal number of octets, for any message other than a + response to the HEAD method or a response with a status code of 304. + In the case of responses to the HEAD method, it indicates the size of + the payload body (not including any potential transfer-coding) that + would have been sent had the request been a GET. In the case of the + 304 (Not Modified) response, it indicates the size of the payload + body (not including any potential transfer-coding) that would have + been sent in a 200 (OK) response. + + Content-Length = "Content-Length" ":" OWS 1*Content-Length-v + Content-Length-v = 1*DIGIT + + An example is + + + +Fielding, et al. Expires February 5, 2011 [Page 50] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + Content-Length: 3495 + + Implementations SHOULD use this field to indicate the message-body + length when no transfer-coding is being applied and the payload's + body length can be determined prior to being transferred. + Section 3.3 describes how recipients determine the length of a + message-body. + + Any Content-Length greater than or equal to zero is a valid value. + + Note that the use of this field in HTTP is significantly different + from the corresponding definition in MIME, where it is an optional + field used within the "message/external-body" content-type. + +9.3. Date + + The "Date" general-header field represents the date and time at which + the message was originated, having the same semantics as the + Origination Date Field (orig-date) defined in Section 3.6.1 of + [RFC5322]. The field value is an HTTP-date, as described in + Section 6.1; it MUST be sent in rfc1123-date format. + + Date = "Date" ":" OWS Date-v + Date-v = HTTP-date + + An example is + + Date: Tue, 15 Nov 1994 08:12:31 GMT + + Origin servers MUST include a Date header field in all responses, + except in these cases: + + 1. If the response status code is 100 (Continue) or 101 (Switching + Protocols), the response MAY include a Date header field, at the + server's option. + + 2. If the response status code conveys a server error, e.g., 500 + (Internal Server Error) or 503 (Service Unavailable), and it is + inconvenient or impossible to generate a valid Date. + + 3. If the server does not have a clock that can provide a reasonable + approximation of the current time, its responses MUST NOT include + a Date header field. In this case, the rules in Section 9.3.1 + MUST be followed. + + A received message that does not have a Date header field MUST be + assigned one by the recipient if the message will be cached by that + recipient or gatewayed via a protocol which requires a Date. An HTTP + + + +Fielding, et al. Expires February 5, 2011 [Page 51] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + implementation without a clock MUST NOT cache responses without + revalidating them on every use. An HTTP cache, especially a shared + cache, SHOULD use a mechanism, such as NTP [RFC1305], to synchronize + its clock with a reliable external standard. + + Clients SHOULD only send a Date header field in messages that include + a payload, as is usually the case for PUT and POST requests, and even + then it is optional. A client without a clock MUST NOT send a Date + header field in a request. + + The HTTP-date sent in a Date header SHOULD NOT represent a date and + time subsequent to the generation of the message. It SHOULD + represent the best available approximation of the date and time of + message generation, unless the implementation has no means of + generating a reasonably accurate date and time. In theory, the date + ought to represent the moment just before the payload is generated. + In practice, the date can be generated at any time during the message + origination without affecting its semantic value. + +9.3.1. Clockless Origin Server Operation + + Some origin server implementations might not have a clock available. + An origin server without a clock MUST NOT assign Expires or Last- + Modified values to a response, unless these values were associated + with the resource by a system or user with a reliable clock. It MAY + assign an Expires value that is known, at or before server + configuration time, to be in the past (this allows "pre-expiration" + of responses without storing separate Expires values for each + resource). + +9.4. Host + + The "Host" request-header field specifies the Internet host and port + number of the resource being requested, allowing the origin server or + gateway to differentiate between internally-ambiguous URLs, such as + the root "/" URL of a server for multiple host names on a single IP + address. + + The Host field value MUST represent the naming authority of the + origin server or gateway given by the original URL obtained from the + user or referring resource (generally an http URI, as described in + Section 2.6.1). + + Host = "Host" ":" OWS Host-v + Host-v = uri-host [ ":" port ] ; Section 2.6.1 + + A "host" without any trailing port information implies the default + port for the service requested (e.g., "80" for an HTTP URL). For + + + +Fielding, et al. Expires February 5, 2011 [Page 52] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + example, a request on the origin server for + <http://www.example.org/pub/WWW/> would properly include: + + GET /pub/WWW/ HTTP/1.1 + Host: www.example.org + + A client MUST include a Host header field in all HTTP/1.1 request + messages. If the requested URI does not include an Internet host + name for the service being requested, then the Host header field MUST + be given with an empty value. An HTTP/1.1 proxy MUST ensure that any + request message it forwards does contain an appropriate Host header + field that identifies the service being requested by the proxy. All + Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request) + status code to any HTTP/1.1 request message which lacks a Host header + field. + + See Sections 4.2 and B.1.1 for other requirements relating to Host. + +9.5. TE + + The "TE" request-header field indicates what extension transfer- + codings it is willing to accept in the response, and whether or not + it is willing to accept trailer fields in a chunked transfer-coding. + + Its value consists of the keyword "trailers" and/or a comma-separated + list of extension transfer-coding names with optional accept + parameters (as described in Section 6.2). + + TE = "TE" ":" OWS TE-v + TE-v = #t-codings + t-codings = "trailers" / ( transfer-extension [ te-params ] ) + te-params = OWS ";" OWS "q=" qvalue *( te-ext ) + te-ext = OWS ";" OWS token [ "=" word ] + + The presence of the keyword "trailers" indicates that the client is + willing to accept trailer fields in a chunked transfer-coding, as + defined in Section 6.2.1. This keyword is reserved for use with + transfer-coding values even though it does not itself represent a + transfer-coding. + + Examples of its use are: + + TE: deflate + TE: + TE: trailers, deflate;q=0.5 + + The TE header field only applies to the immediate connection. + Therefore, the keyword MUST be supplied within a Connection header + + + +Fielding, et al. Expires February 5, 2011 [Page 53] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + field (Section 9.1) whenever TE is present in an HTTP/1.1 message. + + A server tests whether a transfer-coding is acceptable, according to + a TE field, using these rules: + + 1. The "chunked" transfer-coding is always acceptable. If the + keyword "trailers" is listed, the client indicates that it is + willing to accept trailer fields in the chunked response on + behalf of itself and any downstream clients. The implication is + that, if given, the client is stating that either all downstream + clients are willing to accept trailer fields in the forwarded + response, or that it will attempt to buffer the response on + behalf of downstream recipients. + + Note: HTTP/1.1 does not define any means to limit the size of a + chunked response such that a client can be assured of buffering + the entire response. + + 2. If the transfer-coding being tested is one of the transfer- + codings listed in the TE field, then it is acceptable unless it + is accompanied by a qvalue of 0. (As defined in Section 6.4, a + qvalue of 0 means "not acceptable".) + + 3. If multiple transfer-codings are acceptable, then the acceptable + transfer-coding with the highest non-zero qvalue is preferred. + The "chunked" transfer-coding always has a qvalue of 1. + + If the TE field-value is empty or if no TE field is present, the only + transfer-coding is "chunked". A message with no transfer-coding is + always acceptable. + +9.6. Trailer + + The "Trailer" general-header field indicates that the given set of + header fields is present in the trailer of a message encoded with + chunked transfer-coding. + + Trailer = "Trailer" ":" OWS Trailer-v + Trailer-v = 1#field-name + + An HTTP/1.1 message SHOULD include a Trailer header field in a + message using chunked transfer-coding with a non-empty trailer. + Doing so allows the recipient to know which header fields to expect + in the trailer. + + If no Trailer header field is present, the trailer SHOULD NOT include + any header fields. See Section 6.2.1 for restrictions on the use of + trailer fields in a "chunked" transfer-coding. + + + +Fielding, et al. Expires February 5, 2011 [Page 54] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + Message header fields listed in the Trailer header field MUST NOT + include the following header fields: + + o Transfer-Encoding + + o Content-Length + + o Trailer + +9.7. Transfer-Encoding + + The "Transfer-Encoding" general-header field indicates what transfer- + codings (if any) have been applied to the message body. It differs + from Content-Encoding (Section 2.2 of [Part3]) in that transfer- + codings are a property of the message (and therefore are removed by + intermediaries), whereas content-codings are not. + + Transfer-Encoding = "Transfer-Encoding" ":" OWS + Transfer-Encoding-v + Transfer-Encoding-v = 1#transfer-coding + + Transfer-codings are defined in Section 6.2. An example is: + + Transfer-Encoding: chunked + + If multiple encodings have been applied to a representation, the + transfer-codings MUST be listed in the order in which they were + applied. Additional information about the encoding parameters MAY be + provided by other header fields not defined by this specification. + + Many older HTTP/1.0 applications do not understand the Transfer- + Encoding header. + +9.8. Upgrade + + The "Upgrade" general-header field allows the client to specify what + additional communication protocols it would like to use, if the + server chooses to switch protocols. Additionally, the server MUST + use the Upgrade header field within a 101 (Switching Protocols) + response to indicate which protocol(s) are being switched to. + + Upgrade = "Upgrade" ":" OWS Upgrade-v + Upgrade-v = 1#product + + For example, + + Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 + + + + +Fielding, et al. Expires February 5, 2011 [Page 55] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + The Upgrade header field is intended to provide a simple mechanism + for transition from HTTP/1.1 to some other, incompatible protocol. + It does so by allowing the client to advertise its desire to use + another protocol, such as a later version of HTTP with a higher major + version number, even though the current request has been made using + HTTP/1.1. This eases the difficult transition between incompatible + protocols by allowing the client to initiate a request in the more + commonly supported protocol while indicating to the server that it + would like to use a "better" protocol if available (where "better" is + determined by the server, possibly according to the nature of the + method and/or resource being requested). + + The Upgrade header field only applies to switching application-layer + protocols upon the existing transport-layer connection. Upgrade + cannot be used to insist on a protocol change; its acceptance and use + by the server is optional. The capabilities and nature of the + application-layer communication after the protocol change is entirely + dependent upon the new protocol chosen, although the first action + after changing the protocol MUST be a response to the initial HTTP + request containing the Upgrade header field. + + The Upgrade header field only applies to the immediate connection. + Therefore, the upgrade keyword MUST be supplied within a Connection + header field (Section 9.1) whenever Upgrade is present in an HTTP/1.1 + message. + + The Upgrade header field cannot be used to indicate a switch to a + protocol on a different connection. For that purpose, it is more + appropriate to use a 301, 302, 303, or 305 redirection response. + + This specification only defines the protocol name "HTTP" for use by + the family of Hypertext Transfer Protocols, as defined by the HTTP + version rules of Section 2.5 and future updates to this + specification. Additional tokens can be registered with IANA using + the registration procedure defined below. + +9.8.1. Upgrade Token Registry + + The HTTP Upgrade Token Registry defines the name space for product + tokens used to identify protocols in the Upgrade header field. Each + registered token is associated with contact information and an + optional set of specifications that details how the connection will + be processed after it has been upgraded. + + Registrations are allowed on a First Come First Served basis as + described in Section 4.1 of [RFC5226]. The specifications need not + be IETF documents or be subject to IESG review. Registrations are + subject to the following rules: + + + +Fielding, et al. Expires February 5, 2011 [Page 56] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + 1. A token, once registered, stays registered forever. + + 2. The registration MUST name a responsible party for the + registration. + + 3. The registration MUST name a point of contact. + + 4. The registration MAY name a set of specifications associated with + that token. Such specifications need not be publicly available. + + 5. The responsible party MAY change the registration at any time. + The IANA will keep a record of all such changes, and make them + available upon request. + + 6. The responsible party for the first registration of a "product" + token MUST approve later registrations of a "version" token + together with that "product" token before they can be registered. + + 7. If absolutely required, the IESG MAY reassign the responsibility + for a token. This will normally only be used in the case when a + responsible party cannot be contacted. + +9.9. Via + + The "Via" general-header field MUST be used by gateways and proxies + to indicate the intermediate protocols and recipients between the + user agent and the server on requests, and between the origin server + and the client on responses. It is analogous to the "Received" field + defined in Section 3.6.7 of [RFC5322] and is intended to be used for + tracking message forwards, avoiding request loops, and identifying + the protocol capabilities of all senders along the request/response + chain. + + Via = "Via" ":" OWS Via-v + Via-v = 1#( received-protocol RWS received-by + [ RWS comment ] ) + received-protocol = [ protocol-name "/" ] protocol-version + protocol-name = token + protocol-version = token + received-by = ( uri-host [ ":" port ] ) / pseudonym + pseudonym = token + + The received-protocol indicates the protocol version of the message + received by the server or client along each segment of the request/ + response chain. The received-protocol version is appended to the Via + field value when the message is forwarded so that information about + the protocol capabilities of upstream applications remains visible to + all recipients. + + + +Fielding, et al. Expires February 5, 2011 [Page 57] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + The protocol-name is optional if and only if it would be "HTTP". The + received-by field is normally the host and optional port number of a + recipient server or client that subsequently forwarded the message. + However, if the real host is considered to be sensitive information, + it MAY be replaced by a pseudonym. If the port is not given, it MAY + be assumed to be the default port of the received-protocol. + + Multiple Via field values represent each proxy or gateway that has + forwarded the message. Each recipient MUST append its information + such that the end result is ordered according to the sequence of + forwarding applications. + + Comments MAY be used in the Via header field to identify the software + of the recipient proxy or gateway, analogous to the User-Agent and + Server header fields. However, all comments in the Via field are + optional and MAY be removed by any recipient prior to forwarding the + message. + + For example, a request message could be sent from an HTTP/1.0 user + agent to an internal proxy code-named "fred", which uses HTTP/1.1 to + forward the request to a public proxy at p.example.net, which + completes the request by forwarding it to the origin server at + www.example.com. The request received by www.example.com would then + have the following Via header field: + + Via: 1.0 fred, 1.1 p.example.net (Apache/1.1) + + Proxies and gateways used as a portal through a network firewall + SHOULD NOT, by default, forward the names and ports of hosts within + the firewall region. This information SHOULD only be propagated if + explicitly enabled. If not enabled, the received-by host of any host + behind the firewall SHOULD be replaced by an appropriate pseudonym + for that host. + + For organizations that have strong privacy requirements for hiding + internal structures, a proxy MAY combine an ordered subsequence of + Via header field entries with identical received-protocol values into + a single such entry. For example, + + Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy + + could be collapsed to + + Via: 1.0 ricky, 1.1 mertz, 1.0 lucy + + Applications SHOULD NOT combine multiple entries unless they are all + under the same organizational control and the hosts have already been + replaced by pseudonyms. Applications MUST NOT combine entries which + + + +Fielding, et al. Expires February 5, 2011 [Page 58] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + have different received-protocol values. + +10. IANA Considerations + +10.1. Header Field Registration + + The Message Header Field Registry located at <http://www.iana.org/ + assignments/message-headers/message-header-index.html> shall be + updated with the permanent registrations below (see [RFC3864]): + + +-------------------+----------+----------+-------------+ + | Header Field Name | Protocol | Status | Reference | + +-------------------+----------+----------+-------------+ + | Connection | http | standard | Section 9.1 | + | Content-Length | http | standard | Section 9.2 | + | Date | http | standard | Section 9.3 | + | Host | http | standard | Section 9.4 | + | TE | http | standard | Section 9.5 | + | Trailer | http | standard | Section 9.6 | + | Transfer-Encoding | http | standard | Section 9.7 | + | Upgrade | http | standard | Section 9.8 | + | Via | http | standard | Section 9.9 | + +-------------------+----------+----------+-------------+ + + The change controller is: "IETF (iesg@ietf.org) - Internet + Engineering Task Force". + +10.2. URI Scheme Registration + + The entries for the "http" and "https" URI Schemes in the registry + located at <http://www.iana.org/assignments/uri-schemes.html> shall + be updated to point to Sections 2.6.1 and 2.6.2 of this document (see + [RFC4395]). + +10.3. Internet Media Type Registrations + + This document serves as the specification for the Internet media + types "message/http" and "application/http". The following is to be + registered with IANA (see [RFC4288]). + +10.3.1. Internet Media Type message/http + + The message/http type can be used to enclose a single HTTP request or + response message, provided that it obeys the MIME restrictions for + all "message" types regarding line length and encodings. + + + + + + +Fielding, et al. Expires February 5, 2011 [Page 59] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + Type name: message + + Subtype name: http + + Required parameters: none + + Optional parameters: version, msgtype + + version: The HTTP-Version number of the enclosed message (e.g., + "1.1"). If not present, the version can be determined from the + first line of the body. + + msgtype: The message type -- "request" or "response". If not + present, the type can be determined from the first line of the + body. + + Encoding considerations: only "7bit", "8bit", or "binary" are + permitted + + Security considerations: none + + Interoperability considerations: none + + Published specification: This specification (see Section 10.3.1). + + Applications that use this media type: + + Additional information: + + Magic number(s): none + + File extension(s): none + + Macintosh file type code(s): none + + Person and email address to contact for further information: See + Authors Section. + + Intended usage: COMMON + + Restrictions on usage: none + + Author/Change controller: IESG + + + + + + + + +Fielding, et al. Expires February 5, 2011 [Page 60] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + +10.3.2. Internet Media Type application/http + + The application/http type can be used to enclose a pipeline of one or + more HTTP request or response messages (not intermixed). + + Type name: application + + Subtype name: http + + Required parameters: none + + Optional parameters: version, msgtype + + version: The HTTP-Version number of the enclosed messages (e.g., + "1.1"). If not present, the version can be determined from the + first line of the body. + + msgtype: The message type -- "request" or "response". If not + present, the type can be determined from the first line of the + body. + + Encoding considerations: HTTP messages enclosed by this type are in + "binary" format; use of an appropriate Content-Transfer-Encoding + is required when transmitted via E-mail. + + Security considerations: none + + Interoperability considerations: none + + Published specification: This specification (see Section 10.3.2). + + Applications that use this media type: + + Additional information: + + Magic number(s): none + + File extension(s): none + + Macintosh file type code(s): none + + Person and email address to contact for further information: See + Authors Section. + + Intended usage: COMMON + + + + + + +Fielding, et al. Expires February 5, 2011 [Page 61] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + Restrictions on usage: none + + Author/Change controller: IESG + +10.4. Transfer Coding Registry + + The registration procedure for HTTP Transfer Codings is now defined + by Section 6.2.3 of this document. + + The HTTP Transfer Codings Registry located at + <http://www.iana.org/assignments/http-parameters> shall be updated + with the registrations below: + + +----------+--------------------------------------+-----------------+ + | Name | Description | Reference | + +----------+--------------------------------------+-----------------+ + | chunked | Transfer in a series of chunks | Section 6.2.1 | + | compress | UNIX "compress" program method | Section 6.2.2.1 | + | deflate | "deflate" compression mechanism | Section 6.2.2.2 | + | | ([RFC1951]) used inside the "zlib" | | + | | data format ([RFC1950]) | | + | gzip | Same as GNU zip [RFC1952] | Section 6.2.2.3 | + +----------+--------------------------------------+-----------------+ + +10.5. Upgrade Token Registration + + The registration procedure for HTTP Upgrade Tokens -- previously + defined in Section 7.2 of [RFC2817] -- is now defined by + Section 9.8.1 of this document. + + The HTTP Status Code Registry located at + <http://www.iana.org/assignments/http-upgrade-tokens/> shall be + updated with the registration below: + + +-------+---------------------------+-------------------------------+ + | Value | Description | Reference | + +-------+---------------------------+-------------------------------+ + | HTTP | Hypertext Transfer | Section 2.5 of this | + | | Protocol | specification | + +-------+---------------------------+-------------------------------+ + +11. Security Considerations + + This section is meant to inform application developers, information + providers, and users of the security limitations in HTTP/1.1 as + described by this document. The discussion does not include + definitive solutions to the problems revealed, though it does make + some suggestions for reducing security risks. + + + +Fielding, et al. Expires February 5, 2011 [Page 62] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + +11.1. Personal Information + + HTTP clients are often privy to large amounts of personal information + (e.g., the user's name, location, mail address, passwords, encryption + keys, etc.), and SHOULD be very careful to prevent unintentional + leakage of this information. We very strongly recommend that a + convenient interface be provided for the user to control + dissemination of such information, and that designers and + implementors be particularly careful in this area. History shows + that errors in this area often create serious security and/or privacy + problems and generate highly adverse publicity for the implementor's + company. + +11.2. Abuse of Server Log Information + + A server is in the position to save personal data about a user's + requests which might identify their reading patterns or subjects of + interest. This information is clearly confidential in nature and its + handling can be constrained by law in certain countries. People + using HTTP to provide data are responsible for ensuring that such + material is not distributed without the permission of any individuals + that are identifiable by the published results. + +11.3. Attacks Based On File and Path Names + + Implementations of HTTP origin servers SHOULD be careful to restrict + the documents returned by HTTP requests to be only those that were + intended by the server administrators. If an HTTP server translates + HTTP URIs directly into file system calls, the server MUST take + special care not to serve files that were not intended to be + delivered to HTTP clients. For example, UNIX, Microsoft Windows, and + other operating systems use ".." as a path component to indicate a + directory level above the current one. On such a system, an HTTP + server MUST disallow any such construct in the request-target if it + would otherwise allow access to a resource outside those intended to + be accessible via the HTTP server. Similarly, files intended for + reference only internally to the server (such as access control + files, configuration files, and script code) MUST be protected from + inappropriate retrieval, since they might contain sensitive + information. Experience has shown that minor bugs in such HTTP + server implementations have turned into security risks. + +11.4. DNS Spoofing + + Clients using HTTP rely heavily on the Domain Name Service, and are + thus generally prone to security attacks based on the deliberate mis- + association of IP addresses and DNS names. Clients need to be + cautious in assuming the continuing validity of an IP number/DNS name + + + +Fielding, et al. Expires February 5, 2011 [Page 63] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + association. + + In particular, HTTP clients SHOULD rely on their name resolver for + confirmation of an IP number/DNS name association, rather than + caching the result of previous host name lookups. Many platforms + already can cache host name lookups locally when appropriate, and + they SHOULD be configured to do so. It is proper for these lookups + to be cached, however, only when the TTL (Time To Live) information + reported by the name server makes it likely that the cached + information will remain useful. + + If HTTP clients cache the results of host name lookups in order to + achieve a performance improvement, they MUST observe the TTL + information reported by DNS. + + If HTTP clients do not observe this rule, they could be spoofed when + a previously-accessed server's IP address changes. As network + renumbering is expected to become increasingly common [RFC1900], the + possibility of this form of attack will grow. Observing this + requirement thus reduces this potential security vulnerability. + + This requirement also improves the load-balancing behavior of clients + for replicated servers using the same DNS name and reduces the + likelihood of a user's experiencing failure in accessing sites which + use that strategy. + +11.5. Proxies and Caching + + By their very nature, HTTP proxies are men-in-the-middle, and + represent an opportunity for man-in-the-middle attacks. Compromise + of the systems on which the proxies run can result in serious + security and privacy problems. Proxies have access to security- + related information, personal information about individual users and + organizations, and proprietary information belonging to users and + content providers. A compromised proxy, or a proxy implemented or + configured without regard to security and privacy considerations, + might be used in the commission of a wide range of potential attacks. + + Proxy operators need to protect the systems on which proxies run as + they would protect any system that contains or transports sensitive + information. In particular, log information gathered at proxies + often contains highly sensitive personal information, and/or + information about organizations. Log information needs to be + carefully guarded, and appropriate guidelines for use need to be + developed and followed. (Section 11.2). + + Proxy implementors need to consider the privacy and security + implications of their design and coding decisions, and of the + + + +Fielding, et al. Expires February 5, 2011 [Page 64] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + configuration options they provide to proxy operators (especially the + default configuration). + + Users of a proxy need to be aware that proxies are no trustworthier + than the people who run them; HTTP itself cannot solve this problem. + + The judicious use of cryptography, when appropriate, might suffice to + protect against a broad range of security and privacy attacks. Such + cryptography is beyond the scope of the HTTP/1.1 specification. + +11.6. Denial of Service Attacks on Proxies + + They exist. They are hard to defend against. Research continues. + Beware. + +12. Acknowledgments + + HTTP has evolved considerably over the years. It has benefited from + a large and active developer community--the many people who have + participated on the www-talk mailing list--and it is that community + which has been most responsible for the success of HTTP and of the + World-Wide Web in general. Marc Andreessen, Robert Cailliau, Daniel + W. Connolly, Bob Denny, John Franks, Jean-Francois Groff, Phillip M. + Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob McCool, Lou Montulli, + Dave Raggett, Tony Sanders, and Marc VanHeyningen deserve special + recognition for their efforts in defining early aspects of the + protocol. + + This document has benefited greatly from the comments of all those + participating in the HTTP-WG. In addition to those already + mentioned, the following individuals have contributed to this + specification: + + Gary Adams, Harald Tveit Alvestrand, Keith Ball, Brian Behlendorf, + Paul Burchard, Maurizio Codogno, Josh Cohen, Mike Cowlishaw, Roman + Czyborra, Michael A. Dolan, Daniel DuBois, David J. Fiander, Alan + Freier, Marc Hedlund, Greg Herlihy, Koen Holtman, Alex Hopmann, Bob + Jernigan, Shel Kaphan, Rohit Khare, John Klensin, Martijn Koster, + Alexei Kosut, David M. Kristol, Daniel LaLiberte, Ben Laurie, Paul J. + Leach, Albert Lunde, John C. Mallery, Jean-Philippe Martin-Flatin, + Mitra, David Morris, Gavin Nicol, Ross Patterson, Bill Perry, Jeffrey + Perry, Scott Powers, Owen Rees, Luigi Rizzo, David Robinson, Marc + Salomon, Rich Salz, Allan M. Schiffman, Jim Seidman, Chuck Shotton, + Eric W. Sink, Simon E. Spero, Richard N. Taylor, Robert S. Thau, Bill + (BearHeart) Weinman, Francois Yergeau, Mary Ellen Zurko. + + Thanks to the "cave men" of Palo Alto. You know who you are. + + + + +Fielding, et al. Expires February 5, 2011 [Page 65] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + Jim Gettys (the editor of [RFC2616]) wishes particularly to thank Roy + Fielding, the editor of [RFC2068], along with John Klensin, Jeff + Mogul, Paul Leach, Dave Kristol, Koen Holtman, John Franks, Josh + Cohen, Alex Hopmann, Scott Lawrence, and Larry Masinter for their + help. And thanks go particularly to Jeff Mogul and Scott Lawrence + for performing the "MUST/MAY/SHOULD" audit. + + The Apache Group, Anselm Baird-Smith, author of Jigsaw, and Henrik + Frystyk implemented RFC 2068 early, and we wish to thank them for the + discovery of many of the problems that this document attempts to + rectify. + + This specification makes heavy use of the augmented BNF and generic + constructs defined by David H. Crocker for [RFC5234]. Similarly, it + reuses many of the definitions provided by Nathaniel Borenstein and + Ned Freed for MIME [RFC2045]. We hope that their inclusion in this + specification will help reduce past confusion over the relationship + between HTTP and Internet mail message formats. + +13. References + +13.1. Normative References + + [ISO-8859-1] International Organization for Standardization, + "Information technology -- 8-bit single-byte coded + graphic character sets -- Part 1: Latin alphabet No. + 1", ISO/IEC 8859-1:1998, 1998. + + [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., + Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., + Ed., and J. Reschke, Ed., "HTTP/1.1, part 2: Message + Semantics", draft-ietf-httpbis-p2-semantics-11 (work in + progress), August 2010. + + [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., + Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., + Ed., and J. Reschke, Ed., "HTTP/1.1, part 3: Message + Payload and Content Negotiation", + draft-ietf-httpbis-p3-payload-11 (work in progress), + August 2010. + + [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., + Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., + Ed., Nottingham, M., Ed., and J. Reschke, Ed., + "HTTP/1.1, part 6: Caching", + draft-ietf-httpbis-p6-cache-11 (work in progress), + August 2010. + + + + +Fielding, et al. Expires February 5, 2011 [Page 66] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data + Format Specification version 3.3", RFC 1950, May 1996. + + RFC 1950 is an Informational RFC, thus it might be less + stable than this specification. On the other hand, + this downward reference was present since the + publication of RFC 2068 in 1997 ([RFC2068]), therefore + it is unlikely to cause problems in practice. See also + [BCP97]. + + [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format + Specification version 1.3", RFC 1951, May 1996. + + RFC 1951 is an Informational RFC, thus it might be less + stable than this specification. On the other hand, + this downward reference was present since the + publication of RFC 2068 in 1997 ([RFC2068]), therefore + it is unlikely to cause problems in practice. See also + [BCP97]. + + [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and + G. Randers-Pehrson, "GZIP file format specification + version 4.3", RFC 1952, May 1996. + + RFC 1952 is an Informational RFC, thus it might be less + stable than this specification. On the other hand, + this downward reference was present since the + publication of RFC 2068 in 1997 ([RFC2068]), therefore + it is unlikely to cause problems in practice. See also + [BCP97]. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, + "Uniform Resource Identifier (URI): Generic Syntax", + RFC 3986, STD 66, January 2005. + + [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for + Syntax Specifications: ABNF", STD 68, RFC 5234, + January 2008. + + [USASCII] American National Standards Institute, "Coded Character + Set -- 7-bit American Standard Code for Information + Interchange", ANSI X3.4, 1986. + + + + + + +Fielding, et al. Expires February 5, 2011 [Page 67] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + +13.2. Informative References + + [BCP97] Klensin, J. and S. Hartman, "Handling Normative + References to Standards-Track Documents", BCP 97, + RFC 4897, June 2007. + + [Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and + Politics", ACM Transactions on Internet Technology Vol. + 1, #2, November 2001, + <http://arxiv.org/abs/cs.SE/0105018>. + + [Nie1997] Frystyk, H., Gettys, J., Prud'hommeaux, E., Lie, H., + and C. Lilley, "Network Performance Effects of + HTTP/1.1, CSS1, and PNG", ACM Proceedings of the ACM + SIGCOMM '97 conference on Applications, technologies, + architectures, and protocols for computer communication + SIGCOMM '97, September 1997, + <http://doi.acm.org/10.1145/263105.263157>. + + [Pad1995] Padmanabhan, V. and J. Mogul, "Improving HTTP Latency", + Computer Networks and ISDN Systems v. 28, pp. 25-35, + December 1995, + <http://portal.acm.org/citation.cfm?id=219094>. + + [RFC1123] Braden, R., "Requirements for Internet Hosts - + Application and Support", STD 3, RFC 1123, + October 1989. + + [RFC1305] Mills, D., "Network Time Protocol (Version 3) + Specification, Implementation", RFC 1305, March 1992. + + [RFC1900] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", + RFC 1900, February 1996. + + [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, + "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, + May 1996. + + [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet + Mail Extensions (MIME) Part One: Format of Internet + Message Bodies", RFC 2045, November 1996. + + [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail + Extensions) Part Three: Message Header Extensions for + Non-ASCII Text", RFC 2047, November 1996. + + [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and + T. Berners-Lee, "Hypertext Transfer Protocol -- + + + +Fielding, et al. Expires February 5, 2011 [Page 68] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + HTTP/1.1", RFC 2068, January 1997. + + [RFC2109] Kristol, D. and L. Montulli, "HTTP State Management + Mechanism", RFC 2109, February 1997. + + [RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, + "Use and Interpretation of HTTP Version Numbers", + RFC 2145, May 1997. + + [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., + Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext + Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. + + [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within + HTTP/1.1", RFC 2817, May 2000. + + [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. + + [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management + Mechanism", RFC 2965, October 2000. + + [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration + Procedures for Message Header Fields", BCP 90, + RFC 3864, September 2004. + + [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications + and Registration Procedures", BCP 13, RFC 4288, + December 2005. + + [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines + and Registration Procedures for New URI Schemes", + BCP 115, RFC 4395, February 2006. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing + an IANA Considerations Section in RFCs", BCP 26, + RFC 5226, May 2008. + + [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, + October 2008. + + [Spe] Spero, S., "Analysis of HTTP Performance Problems", + <http://sunsite.unc.edu/mdma-release/http-prob.html>. + + [Tou1998] Touch, J., Heidemann, J., and K. Obraczka, "Analysis of + HTTP Performance", ISI Research Report ISI/RR-98-463, + Aug 1998, <http://www.isi.edu/touch/pubs/http-perf96/>. + + (original report dated Aug. 1996) + + + +Fielding, et al. Expires February 5, 2011 [Page 69] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + +Appendix A. Tolerant Applications + + Although this document specifies the requirements for the generation + of HTTP/1.1 messages, not all applications will be correct in their + implementation. We therefore recommend that operational applications + be tolerant of deviations whenever those deviations can be + interpreted unambiguously. + + Clients SHOULD be tolerant in parsing the Status-Line and servers + SHOULD be tolerant when parsing the Request-Line. In particular, + they SHOULD accept any amount of WSP characters between fields, even + though only a single SP is required. + + The line terminator for header fields is the sequence CRLF. However, + we recommend that applications, when parsing such headers, recognize + a single LF as a line terminator and ignore the leading CR. + + The character set of a representation SHOULD be labeled as the lowest + common denominator of the character codes used within that + representation, with the exception that not labeling the + representation is preferred over labeling the representation with the + labels US-ASCII or ISO-8859-1. See [Part3]. + + Additional rules for requirements on parsing and encoding of dates + and other potential problems with date encodings include: + + o HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date + which appears to be more than 50 years in the future is in fact in + the past (this helps solve the "year 2000" problem). + + o Although all date formats are specified to be case-sensitive, + recipients SHOULD match day, week and timezone names case- + insensitively. + + o An HTTP/1.1 implementation MAY internally represent a parsed + Expires date as earlier than the proper value, but MUST NOT + internally represent a parsed Expires date as later than the + proper value. + + o All expiration-related calculations MUST be done in GMT. The + local time zone MUST NOT influence the calculation or comparison + of an age or expiration time. + + o If an HTTP header incorrectly carries a date value with a time + zone other than GMT, it MUST be converted into GMT using the most + conservative possible conversion. + + + + + +Fielding, et al. Expires February 5, 2011 [Page 70] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + +Appendix B. Compatibility with Previous Versions + + HTTP has been in use by the World-Wide Web global information + initiative since 1990. The first version of HTTP, later referred to + as HTTP/0.9, was a simple protocol for hypertext data transfer across + the Internet with only a single method and no metadata. HTTP/1.0, as + defined by [RFC1945], added a range of request methods and MIME-like + messaging that could include 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. The proliferation of incompletely-implemented + applications calling themselves "HTTP/1.0" further necessitated a + protocol version change in order for two communicating applications + to determine each other's true capabilities. + + HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent + requirements that enable reliable implementations, 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. + + It is beyond the scope of a protocol specification to mandate + compliance with previous versions. HTTP/1.1 was deliberately + designed, however, to make supporting previous versions easy. It is + worth noting that, at the time of composing this specification, we + would expect general-purpose HTTP/1.1 servers to: + + o understand any valid request in the format of HTTP/1.0 and 1.1; + + o respond appropriately with a message in the same major version + used by the client. + + And we would expect HTTP/1.1 clients to: + + o understand any valid response in the format of HTTP/1.0 or 1.1. + + For most implementations of HTTP/1.0, each connection is established + by the client prior to the request and closed by the server after + sending the response. Some implementations implement the Keep-Alive + version of persistent connections described in Section 19.7.1 of + [RFC2068]. + +B.1. Changes from HTTP/1.0 + + This section summarizes major differences between versions HTTP/1.0 + and HTTP/1.1. + + + + +Fielding, et al. Expires February 5, 2011 [Page 71] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + +B.1.1. Changes to Simplify Multi-homed Web Servers and Conserve IP + Addresses + + The requirements that clients and servers support the Host request- + header, report an error if the Host request-header (Section 9.4) is + missing from an HTTP/1.1 request, and accept absolute URIs + (Section 4.1.2) are among the most important changes defined by this + specification. + + Older HTTP/1.0 clients assumed a one-to-one relationship of IP + addresses and servers; there was no other established mechanism for + distinguishing the intended server of a request than the IP address + to which that request was directed. The changes outlined above will + allow the Internet, once older HTTP clients are no longer common, to + support multiple Web sites from a single IP address, greatly + simplifying large operational Web servers, where allocation of many + IP addresses to a single host has created serious problems. The + Internet will also be able to recover the IP addresses that have been + allocated for the sole purpose of allowing special-purpose domain + names to be used in root-level HTTP URLs. Given the rate of growth + of the Web, and the number of servers already deployed, it is + extremely important that all implementations of HTTP (including + updates to existing HTTP/1.0 applications) correctly implement these + requirements: + + o Both clients and servers MUST support the Host request-header. + + o A client that sends an HTTP/1.1 request MUST send a Host header. + + o Servers MUST report a 400 (Bad Request) error if an HTTP/1.1 + request does not include a Host request-header. + + o Servers MUST accept absolute URIs. + +B.2. Compatibility with HTTP/1.0 Persistent Connections + + Some clients and servers might wish to be compatible with some + previous implementations of persistent connections in HTTP/1.0 + clients and servers. Persistent connections in HTTP/1.0 are + explicitly negotiated as they are not the default behavior. HTTP/1.0 + experimental implementations of persistent connections are faulty, + and the new facilities in HTTP/1.1 are designed to rectify these + problems. The problem was that some existing HTTP/1.0 clients might + send Keep-Alive to a proxy server that doesn't understand Connection, + which would then erroneously forward it to the next inbound server, + which would establish the Keep-Alive connection and result in a hung + HTTP/1.0 proxy waiting for the close on the response. The result is + that HTTP/1.0 clients must be prevented from using Keep-Alive when + + + +Fielding, et al. Expires February 5, 2011 [Page 72] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + talking to proxies. + + However, talking to proxies is the most important use of persistent + connections, so that prohibition is clearly unacceptable. Therefore, + we need some other mechanism for indicating a persistent connection + is desired, which is safe to use even when talking to an old proxy + that ignores Connection. Persistent connections are the default for + HTTP/1.1 messages; we introduce a new keyword (Connection: close) for + declaring non-persistence. See Section 9.1. + + The original HTTP/1.0 form of persistent connections (the Connection: + Keep-Alive and Keep-Alive header) is documented in Section 19.7.1 of + [RFC2068]. + +B.3. Changes from RFC 2616 + + Empty list elements in list productions have been deprecated. + (Section 1.2.1) + + Rules about implicit linear whitespace between certain grammar + productions have been removed; now it's only allowed when + specifically pointed out in the ABNF. The NUL character is no longer + allowed in comment and quoted-string text. The quoted-pair rule no + longer allows escaping control characters other than HTAB. Non-ASCII + content in header fields and reason phrase has been obsoleted and + made opaque (the TEXT rule was removed) (Section 1.2.2) + + Clarify that HTTP-Version is case sensitive. (Section 2.5) + + Remove reference to non-existent identity transfer-coding value + tokens. (Sections 6.2 and 3.3) + + Require that invalid whitespace around field-names be rejected. + (Section 3.2) + + Update use of abs_path production from RFC1808 to the path-absolute + + query components of RFC3986. (Section 4.1.2) + + Clarification that the chunk length does not include the count of the + octets in the chunk header and trailer. Furthermore disallowed line + folding in chunk extensions. (Section 6.2.1) + + Remove hard limit of two connections per server. (Section 7.1.4) + + Clarify exactly when close connection options must be sent. + (Section 9.1) + +Appendix C. Collected ABNF + + + +Fielding, et al. Expires February 5, 2011 [Page 73] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + BWS = OWS + + Cache-Control = <Cache-Control, defined in [Part6], Section 3.4> + Chunked-Body = *chunk last-chunk trailer-part CRLF + Connection = "Connection:" OWS Connection-v + Connection-v = *( "," OWS ) connection-token *( OWS "," [ OWS + connection-token ] ) + Content-Length = "Content-Length:" OWS 1*Content-Length-v + Content-Length-v = 1*DIGIT + + Date = "Date:" OWS Date-v + Date-v = HTTP-date + + GMT = %x47.4D.54 ; GMT + + HTTP-Prot-Name = %x48.54.54.50 ; HTTP + HTTP-Version = HTTP-Prot-Name "/" 1*DIGIT "." 1*DIGIT + HTTP-date = rfc1123-date / obs-date + HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body + ] + Host = "Host:" OWS Host-v + Host-v = uri-host [ ":" port ] + + MIME-Version = <MIME-Version, defined in [Part3], Appendix A.1> + Method = token + + OWS = *( [ obs-fold ] WSP ) + + Pragma = <Pragma, defined in [Part6], Section 3.4> + + RWS = 1*( [ obs-fold ] WSP ) + Reason-Phrase = *( WSP / VCHAR / obs-text ) + Request = Request-Line *( header-field CRLF ) CRLF [ message-body ] + Request-Line = Method SP request-target SP HTTP-Version CRLF + Response = Status-Line *( header-field CRLF ) CRLF [ message-body ] + + Status-Code = 3DIGIT + Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF + + TE = "TE:" OWS TE-v + TE-v = [ ( "," / t-codings ) *( OWS "," [ OWS t-codings ] ) ] + Trailer = "Trailer:" OWS Trailer-v + Trailer-v = *( "," OWS ) field-name *( OWS "," [ OWS field-name ] ) + Transfer-Encoding = "Transfer-Encoding:" OWS Transfer-Encoding-v + Transfer-Encoding-v = *( "," OWS ) transfer-coding *( OWS "," [ OWS + transfer-coding ] ) + + URI-reference = <URI-reference, defined in [RFC3986], Section 4.1> + + + +Fielding, et al. Expires February 5, 2011 [Page 74] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + Upgrade = "Upgrade:" OWS Upgrade-v + Upgrade-v = *( "," OWS ) product *( OWS "," [ OWS product ] ) + + Via = "Via:" OWS Via-v + Via-v = *( "," OWS ) received-protocol RWS received-by [ RWS comment + ] *( OWS "," [ OWS received-protocol RWS received-by [ RWS comment ] + ] ) + + Warning = <Warning, defined in [Part6], Section 3.6> + + absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3> + asctime-date = day-name SP date3 SP time-of-day SP year + attribute = token + authority = <authority, defined in [RFC3986], Section 3.2> + + chunk = chunk-size *WSP [ chunk-ext ] CRLF chunk-data CRLF + chunk-data = 1*OCTET + chunk-ext = *( ";" *WSP chunk-ext-name [ "=" chunk-ext-val ] *WSP ) + chunk-ext-name = token + chunk-ext-val = token / quoted-str-nf + chunk-size = 1*HEXDIG + comment = "(" *( ctext / quoted-cpair / comment ) ")" + connection-token = token + ctext = OWS / %x21-27 ; '!'-''' + / %x2A-5B ; '*'-'[' + / %x5D-7E ; ']'-'~' + / obs-text + + date1 = day SP month SP year + date2 = day "-" month "-" 2DIGIT + date3 = month SP ( 2DIGIT / ( SP DIGIT ) ) + day = 2DIGIT + day-name = %x4D.6F.6E ; Mon + / %x54.75.65 ; Tue + / %x57.65.64 ; Wed + / %x54.68.75 ; Thu + / %x46.72.69 ; Fri + / %x53.61.74 ; Sat + / %x53.75.6E ; Sun + day-name-l = %x4D.6F.6E.64.61.79 ; Monday + / %x54.75.65.73.64.61.79 ; Tuesday + / %x57.65.64.6E.65.73.64.61.79 ; Wednesday + / %x54.68.75.72.73.64.61.79 ; Thursday + / %x46.72.69.64.61.79 ; Friday + / %x53.61.74.75.72.64.61.79 ; Saturday + / %x53.75.6E.64.61.79 ; Sunday + + field-content = *( WSP / VCHAR / obs-text ) + + + +Fielding, et al. Expires February 5, 2011 [Page 75] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + field-name = token + field-value = *( field-content / OWS ) + + general-header = Cache-Control / Connection / Date / Pragma / Trailer + / Transfer-Encoding / Upgrade / Via / Warning / MIME-Version + + header-field = field-name ":" OWS [ field-value ] OWS + hour = 2DIGIT + http-URI = "http://" authority path-abempty [ "?" query ] + https-URI = "https://" authority path-abempty [ "?" query ] + + last-chunk = 1*"0" *WSP [ chunk-ext ] CRLF + + message-body = *OCTET + minute = 2DIGIT + month = %x4A.61.6E ; Jan + / %x46.65.62 ; Feb + / %x4D.61.72 ; Mar + / %x41.70.72 ; Apr + / %x4D.61.79 ; May + / %x4A.75.6E ; Jun + / %x4A.75.6C ; Jul + / %x41.75.67 ; Aug + / %x53.65.70 ; Sep + / %x4F.63.74 ; Oct + / %x4E.6F.76 ; Nov + / %x44.65.63 ; Dec + + obs-date = rfc850-date / asctime-date + obs-fold = CRLF + obs-text = %x80-FF + + partial-URI = relative-part [ "?" query ] + path-abempty = <path-abempty, defined in [RFC3986], Section 3.3> + path-absolute = <path-absolute, defined in [RFC3986], Section 3.3> + port = <port, defined in [RFC3986], Section 3.2.3> + product = token [ "/" product-version ] + product-version = token + protocol-name = token + protocol-version = token + pseudonym = token + + qdtext = OWS / "!" / %x23-5B ; '#'-'[' + / %x5D-7E ; ']'-'~' + / obs-text + qdtext-nf = WSP / "!" / %x23-5B ; '#'-'[' + / %x5D-7E ; ']'-'~' + / obs-text + + + +Fielding, et al. Expires February 5, 2011 [Page 76] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + query = <query, defined in [RFC3986], Section 3.4> + quoted-cpair = "\" ( WSP / VCHAR / obs-text ) + quoted-pair = "\" ( WSP / VCHAR / obs-text ) + quoted-str-nf = DQUOTE *( qdtext-nf / quoted-pair ) DQUOTE + quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE + qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] ) + + received-by = ( uri-host [ ":" port ] ) / pseudonym + received-protocol = [ protocol-name "/" ] protocol-version + relative-part = <relative-part, defined in [RFC3986], Section 4.2> + request-header = <request-header, defined in [Part2], Section 3> + request-target = "*" / absolute-URI / ( path-absolute [ "?" query ] ) + / authority + response-header = <response-header, defined in [Part2], Section 5> + rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT + rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT + + second = 2DIGIT + special = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" / + DQUOTE / "/" / "[" / "]" / "?" / "=" / "{" / "}" + start-line = Request-Line / Status-Line + + t-codings = "trailers" / ( transfer-extension [ te-params ] ) + tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." / + "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA + te-ext = OWS ";" OWS token [ "=" word ] + te-params = OWS ";" OWS "q=" qvalue *te-ext + time-of-day = hour ":" minute ":" second + token = 1*tchar + trailer-part = *( header-field CRLF ) + transfer-coding = "chunked" / "compress" / "deflate" / "gzip" / + transfer-extension + transfer-extension = token *( OWS ";" OWS transfer-parameter ) + transfer-parameter = attribute BWS "=" BWS value + + uri-host = <host, defined in [RFC3986], Section 3.2.2> + + value = word + + word = token / quoted-string + + year = 4DIGIT + + + + + + + + + +Fielding, et al. Expires February 5, 2011 [Page 77] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + ABNF diagnostics: + + ; Chunked-Body defined but not used + ; Content-Length defined but not used + ; HTTP-message defined but not used + ; Host defined but not used + ; Request defined but not used + ; Response defined but not used + ; TE defined but not used + ; URI-reference defined but not used + ; general-header defined but not used + ; http-URI defined but not used + ; https-URI defined but not used + ; partial-URI defined but not used + ; request-header defined but not used + ; response-header defined but not used + ; special defined but not used + +Appendix D. Change Log (to be removed by RFC Editor before publication) + +D.1. Since RFC2616 + + Extracted relevant partitions from [RFC2616]. + +D.2. Since draft-ietf-httpbis-p1-messaging-00 + + Closed issues: + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/1>: "HTTP Version + should be case sensitive" + (<http://purl.org/NET/http-errata#verscase>) + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/2>: "'unsafe' + characters" (<http://purl.org/NET/http-errata#unsafe-uri>) + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/3>: "Chunk Size + Definition" (<http://purl.org/NET/http-errata#chunk-size>) + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/4>: "Message Length" + (<http://purl.org/NET/http-errata#msg-len-chars>) + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/8>: "Media Type + Registrations" (<http://purl.org/NET/http-errata#media-reg>) + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/11>: "URI includes + query" (<http://purl.org/NET/http-errata#uriquery>) + + + + + +Fielding, et al. Expires February 5, 2011 [Page 78] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/15>: "No close on + 1xx responses" (<http://purl.org/NET/http-errata#noclose1xx>) + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/16>: "Remove + 'identity' token references" + (<http://purl.org/NET/http-errata#identity>) + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/26>: "Import query + BNF" + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/31>: "qdtext BNF" + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and + Informative references" + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/42>: "RFC2606 + Compliance" + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/45>: "RFC977 + reference" + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/46>: "RFC1700 + references" + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/47>: "inconsistency + in date format explanation" + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/48>: "Date reference + typo" + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/65>: "Informative + references" + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/66>: "ISO-8859-1 + Reference" + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/86>: "Normative up- + to-date references" + + Other changes: + + o Update media type registrations to use RFC4288 template. + + o Use names of RFC4234 core rules DQUOTE and WSP, fix broken ABNF + for chunk-data (work in progress on + <http://tools.ietf.org/wg/httpbis/trac/ticket/36>) + + + + + +Fielding, et al. Expires February 5, 2011 [Page 79] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + +D.3. Since draft-ietf-httpbis-p1-messaging-01 + + Closed issues: + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/19>: "Bodies on GET + (and other) requests" + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/55>: "Updating to + RFC4288" + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/57>: "Status Code + and Reason Phrase" + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/82>: "rel_path not + used" + + Ongoing work on ABNF conversion + (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): + + o Get rid of duplicate BNF rule names ("host" -> "uri-host", + "trailer" -> "trailer-part"). + + o Avoid underscore character in rule names ("http_URL" -> "http- + URL", "abs_path" -> "path-absolute"). + + o Add rules for terms imported from URI spec ("absoluteURI", + "authority", "path-absolute", "port", "query", "relativeURI", + "host) -- these will have to be updated when switching over to + RFC3986. + + o Synchronize core rules with RFC5234. + + o Get rid of prose rules that span multiple lines. + + o Get rid of unused rules LOALPHA and UPALPHA. + + o Move "Product Tokens" section (back) into Part 1, as "token" is + used in the definition of the Upgrade header. + + o Add explicit references to BNF syntax and rules imported from + other parts of the specification. + + o Rewrite prose rule "token" in terms of "tchar", rewrite prose rule + "TEXT". + + + + + + + +Fielding, et al. Expires February 5, 2011 [Page 80] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + +D.4. Since draft-ietf-httpbis-p1-messaging-02 + + Closed issues: + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/51>: "HTTP-date vs. + rfc1123-date" + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/64>: "WS in quoted- + pair" + + Ongoing work on IANA Message Header Registration + (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>): + + o Reference RFC 3984, and update header registrations for headers + defined in this document. + + Ongoing work on ABNF conversion + (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): + + o Replace string literals when the string really is case-sensitive + (HTTP-Version). + +D.5. Since draft-ietf-httpbis-p1-messaging-03 + + Closed issues: + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/28>: "Connection + closing" + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/97>: "Move + registrations and registry information to IANA Considerations" + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/120>: "need new URL + for PAD1995 reference" + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/127>: "IANA + Considerations: update HTTP URI scheme registration" + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/128>: "Cite HTTPS + URI scheme definition" + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/129>: "List-type + headers vs Set-Cookie" + + Ongoing work on ABNF conversion + (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): + + + + + +Fielding, et al. Expires February 5, 2011 [Page 81] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + o Replace string literals when the string really is case-sensitive + (HTTP-Date). + + o Replace HEX by HEXDIG for future consistence with RFC 5234's core + rules. + +D.6. Since draft-ietf-httpbis-p1-messaging-04 + + Closed issues: + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/34>: "Out-of-date + reference for URIs" + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/132>: "RFC 2822 is + updated by RFC 5322" + + Ongoing work on ABNF conversion + (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): + + o Use "/" instead of "|" for alternatives. + + o Get rid of RFC822 dependency; use RFC5234 plus extensions instead. + + o Only reference RFC 5234's core rules. + + o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional + whitespace ("OWS") and required whitespace ("RWS"). + + o Rewrite ABNFs to spell out whitespace rules, factor out header + value format definitions. + +D.7. Since draft-ietf-httpbis-p1-messaging-05 + + Closed issues: + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/30>: "Header LWS" + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/52>: "Sort 1.3 + Terminology" + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/63>: "RFC2047 + encoded words" + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/74>: "Character + Encodings in TEXT" + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/77>: "Line Folding" + + + + +Fielding, et al. Expires February 5, 2011 [Page 82] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/83>: "OPTIONS * and + proxies" + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/94>: "Reason-Phrase + BNF" + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/111>: "Use of TEXT" + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/118>: "Join + "Differences Between HTTP Entities and RFC 2045 Entities"?" + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/134>: "RFC822 + reference left in discussion of date formats" + + Final work on ABNF conversion + (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): + + o Rewrite definition of list rules, deprecate empty list elements. + + o Add appendix containing collected and expanded ABNF. + + Other changes: + + o Rewrite introduction; add mostly new Architecture Section. + + o Move definition of quality values from Part 3 into Part 1; make TE + request header grammar independent of accept-params (defined in + Part 3). + +D.8. Since draft-ietf-httpbis-p1-messaging-06 + + Closed issues: + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/161>: "base for + numeric protocol elements" + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/162>: "comment ABNF" + + Partly resolved issues: + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/88>: "205 Bodies" + (took out language that implied that there might be methods for + which a request body MUST NOT be included) + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/163>: "editorial + improvements around HTTP-date" + + + + + +Fielding, et al. Expires February 5, 2011 [Page 83] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + +D.9. Since draft-ietf-httpbis-p1-messaging-07 + + Closed issues: + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/93>: "Repeating + single-value headers" + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/131>: "increase + connection limit" + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/157>: "IP addresses + in URLs" + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/172>: "take over + HTTP Upgrade Token Registry" + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/173>: "CR and LF in + chunk extension values" + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/184>: "HTTP/0.9 + support" + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/188>: "pick IANA + policy (RFC5226) for Transfer Coding / Content Coding" + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/189>: "move + definitions of gzip/deflate/compress to part 1" + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/194>: "disallow + control characters in quoted-pair" + + Partly resolved issues: + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/148>: "update IANA + requirements wrt Transfer-Coding values" (add the IANA + Considerations subsection) + +D.10. Since draft-ietf-httpbis-p1-messaging-08 + + Closed issues: + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/201>: "header + parsing, treatment of leading and trailing OWS" + + Partly resolved issues: + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/60>: "Placement of + 13.5.1 and 13.5.2" + + + +Fielding, et al. Expires February 5, 2011 [Page 84] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/200>: "use of term + "word" when talking about header structure" + +D.11. Since draft-ietf-httpbis-p1-messaging-09 + + Closed issues: + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/73>: "Clarification + of the term 'deflate'" + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/83>: "OPTIONS * and + proxies" + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/122>: "MIME-Version + not listed in P1, general header fields" + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/143>: "IANA registry + for content/transfer encodings" + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/165>: "Case- + sensitivity of HTTP-date" + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/200>: "use of term + "word" when talking about header structure" + + Partly resolved issues: + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/196>: "Term for the + requested resource's URI" + +D.12. Since draft-ietf-httpbis-p1-messaging-10 + + Closed issues: + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/28>: "Connection + Closing" + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/90>: "Delimiting + messages with multipart/byteranges" + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/95>: "Handling + multiple Content-Length headers" + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/109>: "Clarify + entity / representation / variant terminology" + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider + removing the 'changes from 2068' sections" + + + +Fielding, et al. Expires February 5, 2011 [Page 85] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + Partly resolved issues: + + o <http://tools.ietf.org/wg/httpbis/trac/ticket/159>: "HTTP(s) URI + scheme definitions" + +Index + + A + application/http Media Type 61 + + B + browser 10 + + C + cache 13 + cacheable 14 + chunked (Coding Format) 35 + client 10 + Coding Format + chunked 35 + compress 38 + deflate 38 + gzip 38 + compress (Coding Format) 38 + connection 10 + Connection header 49 + Content-Length header 50 + + D + Date header 51 + deflate (Coding Format) 38 + downstream 12 + + E + effective request URI 29 + + G + gateway 13 + Grammar + absolute-URI 16 + ALPHA 7 + asctime-date 34 + attribute 34 + authority 16 + BWS 9 + chunk 35 + chunk-data 35 + chunk-ext 35 + + + +Fielding, et al. Expires February 5, 2011 [Page 86] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + chunk-ext-name 35 + chunk-ext-val 35 + chunk-size 35 + Chunked-Body 35 + comment 22 + Connection 49 + connection-token 49 + Connection-v 49 + Content-Length 50 + Content-Length-v 50 + CR 7 + CRLF 7 + ctext 22 + CTL 7 + Date 51 + Date-v 51 + date1 33 + date2 34 + date3 34 + day 33 + day-name 33 + day-name-l 33 + DIGIT 7 + DQUOTE 7 + extension-code 32 + extension-method 26 + field-content 20 + field-name 20 + field-value 20 + general-header 26 + GMT 33 + header-field 20 + HEXDIG 7 + Host 52 + Host-v 52 + hour 33 + HTTP-date 32 + HTTP-message 19 + HTTP-Prot-Name 15 + http-URI 16 + HTTP-Version 15 + https-URI 18 + last-chunk 35 + LF 7 + message-body 22 + Method 26 + minute 33 + month 33 + + + +Fielding, et al. Expires February 5, 2011 [Page 87] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + obs-date 33 + obs-text 10 + OCTET 7 + OWS 9 + path-absolute 16 + port 16 + product 39 + product-version 39 + protocol-name 57 + protocol-version 57 + pseudonym 57 + qdtext 10 + qdtext-nf 35 + query 16 + quoted-cpair 22 + quoted-pair 10 + quoted-str-nf 35 + quoted-string 10 + qvalue 39 + Reason-Phrase 32 + received-by 57 + received-protocol 57 + Request 26 + Request-Line 26 + request-target 27 + Response 31 + rfc850-date 34 + rfc1123-date 33 + RWS 9 + second 33 + SP 7 + special 9 + Status-Code 32 + Status-Line 31 + t-codings 53 + tchar 9 + TE 53 + te-ext 53 + te-params 53 + TE-v 53 + time-of-day 33 + token 9 + Trailer 54 + trailer-part 35 + Trailer-v 54 + transfer-coding 34 + Transfer-Encoding 55 + Transfer-Encoding-v 55 + + + +Fielding, et al. Expires February 5, 2011 [Page 88] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + transfer-extension 34 + transfer-parameter 34 + Upgrade 55 + Upgrade-v 55 + uri-host 16 + URI-reference 16 + value 34 + VCHAR 7 + Via 57 + Via-v 57 + word 9 + WSP 7 + year 33 + gzip (Coding Format) 38 + + H + header field 19 + header section 19 + Headers + Connection 49 + Content-Length 50 + Date 51 + Host 52 + TE 53 + Trailer 54 + Transfer-Encoding 55 + Upgrade 55 + Via 57 + headers 19 + Host header 52 + http URI scheme 16 + https URI scheme 18 + + I + inbound 12 + intermediary 12 + + M + Media Type + application/http 61 + message/http 59 + message 11 + message/http Media Type 59 + + O + origin server 10 + outbound 12 + + + + +Fielding, et al. Expires February 5, 2011 [Page 89] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + P + proxy 12 + + R + request 11 + resource 16 + response 11 + reverse proxy 13 + + S + server 10 + spider 10 + + T + target resource 29 + TE header 53 + Trailer header 54 + Transfer-Encoding header 55 + tunnel 13 + + U + Upgrade header 55 + upstream 12 + URI scheme + http 16 + https 18 + user agent 10 + + V + Via header 57 + +Authors' Addresses + + Roy T. Fielding (editor) + Day Software + 23 Corporate Plaza DR, Suite 280 + Newport Beach, CA 92660 + USA + + Phone: +1-949-706-5300 + Fax: +1-949-706-5305 + EMail: fielding@gbiv.com + URI: http://roy.gbiv.com/ + + + + + + + + +Fielding, et al. Expires February 5, 2011 [Page 90] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + Jim Gettys + Alcatel-Lucent Bell Labs + 21 Oak Knoll Road + Carlisle, MA 01741 + USA + + EMail: jg@freedesktop.org + URI: http://gettys.wordpress.com/ + + + Jeffrey C. Mogul + Hewlett-Packard Company + HP Labs, Large Scale Systems Group + 1501 Page Mill Road, MS 1177 + Palo Alto, CA 94304 + USA + + EMail: JeffMogul@acm.org + + + Henrik Frystyk Nielsen + Microsoft Corporation + 1 Microsoft Way + Redmond, WA 98052 + USA + + EMail: henrikn@microsoft.com + + + Larry Masinter + Adobe Systems, Incorporated + 345 Park Ave + San Jose, CA 95110 + USA + + EMail: LMM@acm.org + URI: http://larry.masinter.net/ + + + Paul J. Leach + Microsoft Corporation + 1 Microsoft Way + Redmond, WA 98052 + + EMail: paulle@microsoft.com + + + + + + +Fielding, et al. Expires February 5, 2011 [Page 91] + +Internet-Draft HTTP/1.1, Part 1 August 2010 + + + Tim Berners-Lee + World Wide Web Consortium + MIT Computer Science and Artificial Intelligence Laboratory + The Stata Center, Building 32 + 32 Vassar Street + Cambridge, MA 02139 + USA + + EMail: timbl@w3.org + URI: http://www.w3.org/People/Berners-Lee/ + + + Yves Lafon (editor) + World Wide Web Consortium + W3C / ERCIM + 2004, rte des Lucioles + Sophia-Antipolis, AM 06902 + France + + EMail: ylafon@w3.org + URI: http://www.raubacapeu.net/people/yves/ + + + Julian F. Reschke (editor) + greenbytes GmbH + Hafenweg 16 + Muenster, NW 48155 + Germany + + Phone: +49 251 2807760 + Fax: +49 251 2807761 + EMail: julian.reschke@greenbytes.de + URI: http://greenbytes.de/tech/webdav/ + + + + + + + + + + + + + + + + + + +Fielding, et al. Expires February 5, 2011 [Page 92] + |