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, 0 insertions, 5152 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 deleted file mode 100644 index c0d449877..000000000 --- a/vendor/sabre/dav/docs/draft-ietf-httpbis-p1-messaging-11.txt +++ /dev/null @@ -1,5152 +0,0 @@ - - - -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] - |