draft-ietf-httpbis-p2-semantics-22.txt   draft-ietf-httpbis-p2-semantics-23.txt 
HTTPbis Working Group R. Fielding, Ed. HTTPbis Working Group R. Fielding, Ed.
Internet-Draft Adobe Internet-Draft Adobe
Obsoletes: 2616 (if approved) J. Reschke, Ed. Obsoletes: 2616 (if approved) J. Reschke, Ed.
Updates: 2817 (if approved) greenbytes Updates: 2817 (if approved) greenbytes
Intended status: Standards Track February 23, 2013 Intended status: Standards Track July 15, 2013
Expires: August 27, 2013 Expires: January 16, 2014
Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
draft-ietf-httpbis-p2-semantics-22 draft-ietf-httpbis-p2-semantics-23
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is an application-level The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypertext information protocol for distributed, collaborative, hypertext information
systems. This document defines the semantics of HTTP/1.1 messages, systems. This document defines the semantics of HTTP/1.1 messages,
as expressed by request methods, request header fields, response as expressed by request methods, request header fields, response
status codes, and response header fields, along with the payload of status codes, and response header fields, along with the payload of
messages (metadata and body content) and mechanisms for content messages (metadata and body content) and mechanisms for content
negotiation. negotiation.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
Discussion of this draft takes place on the HTTPBIS working group Discussion of this draft takes place on the HTTPBIS working group
mailing list (ietf-http-wg@w3.org), which is archived at mailing list (ietf-http-wg@w3.org), which is archived at
<http://lists.w3.org/Archives/Public/ietf-http-wg/>. <http://lists.w3.org/Archives/Public/ietf-http-wg/>.
The current issues list is at The current issues list is at
<http://tools.ietf.org/wg/httpbis/trac/report/3> and related <http://tools.ietf.org/wg/httpbis/trac/report/3> and related
documents (including fancy diffs) can be found at documents (including fancy diffs) can be found at
<http://tools.ietf.org/wg/httpbis/>. <http://tools.ietf.org/wg/httpbis/>.
The changes in this draft are summarized in Appendix E.2. The changes in this draft are summarized in Appendix E.3.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 27, 2013. This Internet-Draft will expire on January 16, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 29 skipping to change at page 3, line 29
5.1.1. Expect . . . . . . . . . . . . . . . . . . . . . . . . 33 5.1.1. Expect . . . . . . . . . . . . . . . . . . . . . . . . 33
5.1.2. Max-Forwards . . . . . . . . . . . . . . . . . . . . . 36 5.1.2. Max-Forwards . . . . . . . . . . . . . . . . . . . . . 36
5.2. Conditionals . . . . . . . . . . . . . . . . . . . . . . . 36 5.2. Conditionals . . . . . . . . . . . . . . . . . . . . . . . 36
5.3. Content Negotiation . . . . . . . . . . . . . . . . . . . 37 5.3. Content Negotiation . . . . . . . . . . . . . . . . . . . 37
5.3.1. Quality Values . . . . . . . . . . . . . . . . . . . . 37 5.3.1. Quality Values . . . . . . . . . . . . . . . . . . . . 37
5.3.2. Accept . . . . . . . . . . . . . . . . . . . . . . . . 38 5.3.2. Accept . . . . . . . . . . . . . . . . . . . . . . . . 38
5.3.3. Accept-Charset . . . . . . . . . . . . . . . . . . . . 40 5.3.3. Accept-Charset . . . . . . . . . . . . . . . . . . . . 40
5.3.4. Accept-Encoding . . . . . . . . . . . . . . . . . . . 41 5.3.4. Accept-Encoding . . . . . . . . . . . . . . . . . . . 41
5.3.5. Accept-Language . . . . . . . . . . . . . . . . . . . 42 5.3.5. Accept-Language . . . . . . . . . . . . . . . . . . . 42
5.4. Authentication Credentials . . . . . . . . . . . . . . . . 43 5.4. Authentication Credentials . . . . . . . . . . . . . . . . 43
5.5. Request Context . . . . . . . . . . . . . . . . . . . . . 43 5.5. Request Context . . . . . . . . . . . . . . . . . . . . . 44
5.5.1. From . . . . . . . . . . . . . . . . . . . . . . . . . 44 5.5.1. From . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.5.2. Referer . . . . . . . . . . . . . . . . . . . . . . . 44 5.5.2. Referer . . . . . . . . . . . . . . . . . . . . . . . 44
5.5.3. User-Agent . . . . . . . . . . . . . . . . . . . . . . 45 5.5.3. User-Agent . . . . . . . . . . . . . . . . . . . . . . 45
6. Response Status Codes . . . . . . . . . . . . . . . . . . . . 46 6. Response Status Codes . . . . . . . . . . . . . . . . . . . . 47
6.1. Overview of Status Codes . . . . . . . . . . . . . . . . . 47 6.1. Overview of Status Codes . . . . . . . . . . . . . . . . . 47
6.2. Informational 1xx . . . . . . . . . . . . . . . . . . . . 49 6.2. Informational 1xx . . . . . . . . . . . . . . . . . . . . 49
6.2.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 49 6.2.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 49
6.2.2. 101 Switching Protocols . . . . . . . . . . . . . . . 50 6.2.2. 101 Switching Protocols . . . . . . . . . . . . . . . 50
6.3. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 50 6.3. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 50
6.3.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 50 6.3.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 50
6.3.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 51 6.3.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 51
6.3.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 51 6.3.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 51
6.3.4. 203 Non-Authoritative Information . . . . . . . . . . 51 6.3.4. 203 Non-Authoritative Information . . . . . . . . . . 51
6.3.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 52 6.3.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 52
skipping to change at page 4, line 46 skipping to change at page 4, line 46
7.4. Response Context . . . . . . . . . . . . . . . . . . . . . 70 7.4. Response Context . . . . . . . . . . . . . . . . . . . . . 70
7.4.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . 71 7.4.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . 71
7.4.2. Server . . . . . . . . . . . . . . . . . . . . . . . . 71 7.4.2. Server . . . . . . . . . . . . . . . . . . . . . . . . 71
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 72
8.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 72 8.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 72
8.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 72 8.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 72
8.1.2. Considerations for New Methods . . . . . . . . . . . . 72 8.1.2. Considerations for New Methods . . . . . . . . . . . . 72
8.1.3. Registrations . . . . . . . . . . . . . . . . . . . . 73 8.1.3. Registrations . . . . . . . . . . . . . . . . . . . . 73
8.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 73 8.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 73
8.2.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 73 8.2.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 73
8.2.2. Considerations for New Status Codes . . . . . . . . . 73 8.2.2. Considerations for New Status Codes . . . . . . . . . 74
8.2.3. Registrations . . . . . . . . . . . . . . . . . . . . 74 8.2.3. Registrations . . . . . . . . . . . . . . . . . . . . 75
8.3. Header Field Registry . . . . . . . . . . . . . . . . . . 75 8.3. Header Field Registry . . . . . . . . . . . . . . . . . . 76
8.3.1. Considerations for New Header Fields . . . . . . . . . 76 8.3.1. Considerations for New Header Fields . . . . . . . . . 77
8.3.2. Registrations . . . . . . . . . . . . . . . . . . . . 78 8.3.2. Registrations . . . . . . . . . . . . . . . . . . . . 79
8.4. Content Coding Registry . . . . . . . . . . . . . . . . . 78 8.4. Content Coding Registry . . . . . . . . . . . . . . . . . 79
8.4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 78 8.4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 79
8.4.2. Registrations . . . . . . . . . . . . . . . . . . . . 79 8.4.2. Registrations . . . . . . . . . . . . . . . . . . . . 80
9. Security Considerations . . . . . . . . . . . . . . . . . . . 79 9. Security Considerations . . . . . . . . . . . . . . . . . . . 80
9.1. Attacks Based On File and Path Names . . . . . . . . . . . 79 9.1. Attacks Based On File and Path Names . . . . . . . . . . . 80
9.2. Personal Information . . . . . . . . . . . . . . . . . . . 80 9.2. Personal Information . . . . . . . . . . . . . . . . . . . 81
9.3. Sensitive Information in URIs . . . . . . . . . . . . . . 80 9.3. Sensitive Information in URIs . . . . . . . . . . . . . . 81
9.4. Product Information . . . . . . . . . . . . . . . . . . . 81 9.4. Product Information . . . . . . . . . . . . . . . . . . . 82
9.5. Fragment after Redirects . . . . . . . . . . . . . . . . . 81 9.5. Fragment after Redirects . . . . . . . . . . . . . . . . . 82
9.6. Browser Fingerprinting . . . . . . . . . . . . . . . . . . 81 9.6. Browser Fingerprinting . . . . . . . . . . . . . . . . . . 82
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 82 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 83
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 82 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 83
11.1. Normative References . . . . . . . . . . . . . . . . . . . 82 11.1. Normative References . . . . . . . . . . . . . . . . . . . 83
11.2. Informative References . . . . . . . . . . . . . . . . . . 84 11.2. Informative References . . . . . . . . . . . . . . . . . . 85
Appendix A. Differences between HTTP and MIME . . . . . . . . . . 85 Appendix A. Differences between HTTP and MIME . . . . . . . . . . 87
A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 86 A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 87
A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 86 A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 87
A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 86 A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 88
A.4. Conversion of Content-Encoding . . . . . . . . . . . . . . 87 A.4. Conversion of Content-Encoding . . . . . . . . . . . . . . 88
A.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 87 A.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 88
A.6. MHTML and Line Length Limitations . . . . . . . . . . . . 87 A.6. MHTML and Line Length Limitations . . . . . . . . . . . . 88
Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 87 Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 89
Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . . 90 Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . . 91
Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 90 Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 92
Appendix E. Change Log (to be removed by RFC Editor before Appendix E. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 93 publication) . . . . . . . . . . . . . . . . . . . . 95
E.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 93 E.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 95
E.2. Since draft-ietf-httpbis-p2-semantics-21 . . . . . . . . . 94 E.2. Since draft-ietf-httpbis-p2-semantics-21 . . . . . . . . . 95
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 E.3. Since draft-ietf-httpbis-p2-semantics-22 . . . . . . . . . 96
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
1. Introduction 1. Introduction
Each Hypertext Transfer Protocol (HTTP) message is either a request Each Hypertext Transfer Protocol (HTTP) message is either a request
or a response. A server listens on a connection for a request, or a response. A server listens on a connection for a request,
parses each message received, interprets the message semantics in parses each message received, interprets the message semantics in
relation to the identified request target, and responds to that relation to the identified request target, and responds to that
request with one or more response messages. A client constructs request with one or more response messages. A client constructs
request messages to communicate specific intentions, and examines request messages to communicate specific intentions, and examines
received responses to see if the intentions were carried out and received responses to see if the intentions were carried out and
skipping to change at page 9, line 26 skipping to change at page 9, line 26
consistency: consistency:
text/html;charset=utf-8 text/html;charset=utf-8
text/html;charset=UTF-8 text/html;charset=UTF-8
Text/HTML;Charset="utf-8" Text/HTML;Charset="utf-8"
text/html; charset="utf-8" text/html; charset="utf-8"
Internet media types ought to be registered with IANA according to Internet media types ought to be registered with IANA according to
the procedures defined in [BCP13]. the procedures defined in [BCP13].
Note: Unlike some similar constructs in other header fields, media
type parameters do not allow whitespace (even "bad" whitespace)
around the "=" character.
3.1.1.2. Charset 3.1.1.2. Charset
HTTP uses charset names to indicate or negotiate the character HTTP uses charset names to indicate or negotiate the character
encoding scheme of a textual representation [RFC6365]. A charset is encoding scheme of a textual representation [RFC6365]. A charset is
identified by a case-insensitive token. identified by a case-insensitive token.
charset = token charset = token
Charset names ought to be registered in IANA Character Set registry Charset names ought to be registered in IANA Character Set registry
(<http://www.iana.org/assignments/character-sets>) according to the (<http://www.iana.org/assignments/character-sets>) according to the
skipping to change at page 13, line 13 skipping to change at page 13, line 13
coding that is not acceptable. coding that is not acceptable.
3.1.3. Audience Language 3.1.3. Audience Language
3.1.3.1. Language Tags 3.1.3.1. Language Tags
A language tag, as defined in [RFC5646], identifies a natural A language tag, as defined in [RFC5646], identifies a natural
language spoken, written, or otherwise conveyed by human beings for language spoken, written, or otherwise conveyed by human beings for
communication of information to other human beings. Computer communication of information to other human beings. Computer
languages are explicitly excluded. HTTP uses language tags within languages are explicitly excluded. HTTP uses language tags within
the Accept-Language and Content-Language fields. the Accept-Language and Content-Language header fields.
Accept-Language uses the looser language-range production defined in
Section 5.3.5, whereas Content-Language uses the stricter language-
tag production defined below.
language-tag = <Language-Tag, defined in [RFC5646], Section 2.1> language-tag = <Language-Tag, defined in [RFC5646], Section 2.1>
A language tag is composed of one or more parts: a primary language A language tag is composed of one or more parts: a primary language
subtag followed by a possibly empty series of subtags. White space subtag followed by a possibly empty series of subtags. White space
is not allowed within the tag and all tags are case-insensitive. is not allowed within the tag and all tags are case-insensitive.
Example tags include: Example tags include:
en, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN en, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN
skipping to change at page 24, line 22 skipping to change at page 24, line 22
It is tempting to think of resource identifiers as remote filesystem It is tempting to think of resource identifiers as remote filesystem
pathnames, and of representations as being a copy of the contents of pathnames, and of representations as being a copy of the contents of
such files. In fact, that is how many resources are implemented (see such files. In fact, that is how many resources are implemented (see
Section 9.1 for related security considerations). However, there are Section 9.1 for related security considerations). However, there are
no such limitations in practice. The HTTP interface for a resource no such limitations in practice. The HTTP interface for a resource
is just as likely to be implemented as a tree of content objects, a is just as likely to be implemented as a tree of content objects, a
programmatic view on various database records, or a gateway to other programmatic view on various database records, or a gateway to other
information systems. Even when the URI mapping mechanism is tied to information systems. Even when the URI mapping mechanism is tied to
a filesystem, an origin server might be configured to execute the a filesystem, an origin server might be configured to execute the
files with the request as input and send the output as the files with the request as input and send the output as the
representation, rather then transfer the files directly. Regardless, representation, rather than transfer the files directly. Regardless,
only the origin server needs to know how each of its resource only the origin server needs to know how each of its resource
identifiers correspond to an implementation, and how each identifiers corresponds to an implementation, and how each
implementation manages to select and send a current representation of implementation manages to select and send a current representation of
the target resource in a response to GET. the target resource in a response to GET.
A client can alter the semantics of GET to be a "range request", A client can alter the semantics of GET to be a "range request",
requesting transfer of only some part(s) of the selected requesting transfer of only some part(s) of the selected
representation, by sending a Range header field in the request representation, by sending a Range header field in the request
([Part5]). ([Part5]).
A payload within a GET request message has no defined semantics; A payload within a GET request message has no defined semantics;
sending a payload body on a GET request might cause some existing sending a payload body on a GET request might cause some existing
skipping to change at page 38, line 34 skipping to change at page 38, line 34
accept-ext = OWS ";" OWS token [ "=" word ] accept-ext = OWS ";" OWS token [ "=" word ]
The asterisk "*" character is used to group media types into ranges, The asterisk "*" character is used to group media types into ranges,
with "*/*" indicating all media types and "type/*" indicating all with "*/*" indicating all media types and "type/*" indicating all
subtypes of that type. The media-range can include media type subtypes of that type. The media-range can include media type
parameters that are applicable to that range. parameters that are applicable to that range.
Each media-range might be followed by zero or more applicable media Each media-range might be followed by zero or more applicable media
type parameters (e.g., charset), an optional "q" parameter for type parameters (e.g., charset), an optional "q" parameter for
indicating a relative weight (Section 5.3.1), and then zero or more indicating a relative weight (Section 5.3.1), and then zero or more
extension parameters. The "q" parameter is necessary if any accept- extension parameters. The "q" parameter is necessary if any
ext are present, since it acts as a separator between the two extensions (accept-ext) are present, since it acts as a separator
parameter sets. between the two parameter sets.
Note: Use of the "q" parameter name to separate media type Note: Use of the "q" parameter name to separate media type
parameters from Accept extension parameters is due to historical parameters from Accept extension parameters is due to historical
practice. Although this prevents any media type parameter named practice. Although this prevents any media type parameter named
"q" from being used with a media range, such an event is believed "q" from being used with a media range, such an event is believed
to be unlikely given the lack of any "q" parameters in the IANA to be unlikely given the lack of any "q" parameters in the IANA
media type registry and the rare usage of any media type media type registry and the rare usage of any media type
parameters in Accept. Future media types are discouraged from parameters in Accept. Future media types are discouraged from
registering any parameter named "q". registering any parameter named "q".
The example The example
Accept: audio/*; q=0.2, audio/basic Accept: audio/*; q=0.2, audio/basic
SHOULD be interpreted as "I prefer audio/basic, but send me any audio SHOULD be interpreted as "I prefer audio/basic, but send me any audio
type if it is the best available after an 80% mark-down in quality". type if it is the best available after an 80% mark-down in quality".
A request without any Accept header field implies that the user agent A request without any Accept header field implies that the user agent
will accept any media type in response. If an Accept header field is will accept any media type in response. If the header field is
present in a request and none of the available representations for present in a request and none of the available representations for
the response have a media type that is listed as acceptable, the the response have a media type that is listed as acceptable, the
origin server MAY either honor the Accept header field by sending a origin server can either honor the header field by sending a 406 (Not
406 (Not Acceptable) response or disregard the Accept header field by Acceptable) response or disregard the header field by treating the
treating the response as if it is not subject to content negotiation. response as if it is not subject to content negotiation.
A more elaborate example is A more elaborate example is
Accept: text/plain; q=0.5, text/html, Accept: text/plain; q=0.5, text/html,
text/x-dvi; q=0.8, text/x-c text/x-dvi; q=0.8, text/x-c
Verbally, this would be interpreted as "text/html and text/x-c are Verbally, this would be interpreted as "text/html and text/x-c are
the equally preferred media types, but if they do not exist, then the equally preferred media types, but if they do not exist, then
send the text/x-dvi representation, and if that does not exist, send send the text/x-dvi representation, and if that does not exist, send
the text/plain representation". the text/plain representation".
skipping to change at page 41, line 5 skipping to change at page 41, line 5
A request without any Accept-Charset header field implies that the A request without any Accept-Charset header field implies that the
user agent will accept any charset in response. Most general-purpose user agent will accept any charset in response. Most general-purpose
user agents do not send Accept-Charset, unless specifically user agents do not send Accept-Charset, unless specifically
configured to do so, because a detailed list of supported charsets configured to do so, because a detailed list of supported charsets
makes it easier for a server to identify an individual by virtue of makes it easier for a server to identify an individual by virtue of
the user agent's request characteristics (Section 9.6). the user agent's request characteristics (Section 9.6).
If an Accept-Charset header field is present in a request and none of If an Accept-Charset header field is present in a request and none of
the available representations for the response has a charset that is the available representations for the response has a charset that is
listed as acceptable, the origin server MAY either honor the Accept- listed as acceptable, the origin server can either honor the header
Charset header field, by sending a 406 (Not Acceptable) response, or field, by sending a 406 (Not Acceptable) response, or disregard the
disregard the Accept-Charset header field by treating the resource as header field by treating the resource as if it is not subject to
if it is not subject to content negotiation. content negotiation.
5.3.4. Accept-Encoding 5.3.4. Accept-Encoding
The "Accept-Encoding" header field can be used by user agents to The "Accept-Encoding" header field can be used by user agents to
indicate what response content-codings (Section 3.1.2.1) are indicate what response content-codings (Section 3.1.2.1) are
acceptable in the response. An "identity" token is used as a synonym acceptable in the response. An "identity" token is used as a synonym
for "no encoding" in order to communicate when no encoding is for "no encoding" in order to communicate when no encoding is
preferred. preferred.
Accept-Encoding = #( codings [ weight ] ) Accept-Encoding = #( codings [ weight ] )
skipping to change at page 42, line 43 skipping to change at page 42, line 43
Each language-range can be given an associated quality value Each language-range can be given an associated quality value
representing an estimate of the user's preference for the languages representing an estimate of the user's preference for the languages
specified by that range, as defined in Section 5.3.1. For example, specified by that range, as defined in Section 5.3.1. For example,
Accept-Language: da, en-gb;q=0.8, en;q=0.7 Accept-Language: da, en-gb;q=0.8, en;q=0.7
would mean: "I prefer Danish, but will accept British English and would mean: "I prefer Danish, but will accept British English and
other types of English". other types of English".
A request without any Accept-Language header field implies that the
user agent will accept any language in response. If the header field
is present in a request and none of the available representations for
the response have a matching language tag, the origin server can
either disregard the header field by treating the response as if it
is not subject to content negotiation, or honor the header field by
sending a 406 (Not Acceptable) response. However, the latter is not
encouraged, as doing so can prevent users from accessing content that
they might be able to use (with translation software, for example).
Note that some recipients treat the order in which language tags are Note that some recipients treat the order in which language tags are
listed as an indication of descending priority, particularly for tags listed as an indication of descending priority, particularly for tags
that are assigned equal quality values (no value is the same as q=1). that are assigned equal quality values (no value is the same as q=1).
However, this behavior cannot be relied upon. For consistency and to However, this behavior cannot be relied upon. For consistency and to
maximize interoperability, many user agents assign each language tag maximize interoperability, many user agents assign each language tag
a unique quality value while also listing them in order of decreasing a unique quality value while also listing them in order of decreasing
quality. Additional discussion of language priority lists can be quality. Additional discussion of language priority lists can be
found in Section 2.3 of [RFC4647]. found in Section 2.3 of [RFC4647].
For matching, Section 3 of [RFC4647] defines several matching For matching, Section 3 of [RFC4647] defines several matching
skipping to change at page 62, line 37 skipping to change at page 62, line 37
6.6.5. 504 Gateway Timeout 6.6.5. 504 Gateway Timeout
The 504 (Gateway Timeout) status code indicates that the server, The 504 (Gateway Timeout) status code indicates that the server,
while acting as a gateway or proxy, did not receive a timely response while acting as a gateway or proxy, did not receive a timely response
from an upstream server it needed to access in order to complete the from an upstream server it needed to access in order to complete the
request. request.
6.6.6. 505 HTTP Version Not Supported 6.6.6. 505 HTTP Version Not Supported
The 505 (HTTP Version Not Supported) status code indicates that the The 505 (HTTP Version Not Supported) status code indicates that the
server does not support, or refuses to support, the protocol version server does not support, or refuses to support, the major version of
that was used in the request message. The server is indicating that HTTP that was used in the request message. The server is indicating
it is unable or unwilling to complete the request using the same that it is unable or unwilling to complete the request using the same
major version as the client, as described in Section 2.6 of [Part1], major version as the client, as described in Section 2.6 of [Part1],
other than with this error message. The server SHOULD generate a other than with this error message. The server SHOULD generate a
representation for the 505 response that describes why that version representation for the 505 response that describes why that version
is not supported and what other protocols are supported by that is not supported and what other protocols are supported by that
server. server.
7. Response Header Fields 7. Response Header Fields
The response header fields allow the server to pass additional The response header fields allow the server to pass additional
information about the response beyond what is placed in the status- information about the response beyond what is placed in the status-
skipping to change at page 68, line 41 skipping to change at page 68, line 41
Two examples of its use are Two examples of its use are
Retry-After: Fri, 31 Dec 1999 23:59:59 GMT Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120 Retry-After: 120
In the latter example, the delay is 2 minutes. In the latter example, the delay is 2 minutes.
7.1.4. Vary 7.1.4. Vary
The "Vary" header field describes what parts of a request message, The "Vary" header field describes what parts of a request message,
aside from the method and request target, might influence the origin aside from the method, the Host header field and the request target,
server's process for selecting and representing the response. The might influence the origin server's process for selecting and
value consists of either a single asterisk ("*") or a list of header representing the response. The value consists of either a single
field names (case-insensitive). asterisk ("*") or a list of header field names (case-insensitive).
Vary = "*" / 1#field-name Vary = "*" / 1#field-name
A Vary field value of "*" signals that anything about the request A Vary field value of "*" signals that anything about the request
might play a role in selecting the response representation, possibly might play a role in selecting the response representation, possibly
including elements outside the message syntax (e.g., the client's including elements outside the message syntax (e.g., the client's
network address), and thus a recipient will not be able to determine network address), and thus a recipient will not be able to determine
whether this response is appropriate for a later request without whether this response is appropriate for a later request without
forwarding the request to the origin server. A proxy MUST NOT forwarding the request to the origin server. A proxy MUST NOT
generate a Vary field with a "*" value. generate a Vary field with a "*" value.
skipping to change at page 72, line 17 skipping to change at page 72, line 17
subproducts by third parties. Overly long and detailed Server field subproducts by third parties. Overly long and detailed Server field
values increase response latency and potentially reveal internal values increase response latency and potentially reveal internal
implementation details that might make it (slightly) easier for implementation details that might make it (slightly) easier for
attackers to find and exploit known security holes. attackers to find and exploit known security holes.
8. IANA Considerations 8. IANA Considerations
8.1. Method Registry 8.1. Method Registry
The HTTP Method Registry defines the name space for the request The HTTP Method Registry defines the name space for the request
method token (Section 4). The method registry is maintained at method token (Section 4). The method registry will be created and
<http://www.iana.org/assignments/http-methods>. maintained at <http://www.iana.org/assignments/http-methods>.
8.1.1. Procedure 8.1.1. Procedure
HTTP method registrations MUST include the following fields: HTTP method registrations MUST include the following fields:
o Method Name (see Section 4) o Method Name (see Section 4)
o Safe ("yes" or "no", see Section 4.2.1) o Safe ("yes" or "no", see Section 4.2.1)
o Idempotent ("yes" or "no", see Section 4.2.2) o Idempotent ("yes" or "no", see Section 4.2.2)
skipping to change at page 73, line 16 skipping to change at page 73, line 16
body if any is present in the request, and what refinements the body if any is present in the request, and what refinements the
method makes to header field or status code semantics. If the new method makes to header field or status code semantics. If the new
method is cacheable, its definition ought to describe how, and under method is cacheable, its definition ought to describe how, and under
what conditions, a cache can store a response and use it to satisfy a what conditions, a cache can store a response and use it to satisfy a
subsequent request. The new method ought to describe whether it can subsequent request. The new method ought to describe whether it can
be made conditional (Section 5.2) and, if so, how a server responds be made conditional (Section 5.2) and, if so, how a server responds
when the condition is false. Likewise, if the new method might have when the condition is false. Likewise, if the new method might have
some use for partial response semantics ([Part5]), it ought to some use for partial response semantics ([Part5]), it ought to
document this too. document this too.
Note: Avoid defining a method name that starts with "M-", since
that prefix might be misinterpreted as having the semantics
assigned to it by [RFC2774].
8.1.3. Registrations 8.1.3. Registrations
The HTTP Method Registry shall be populated with the registrations The HTTP Method Registry shall be populated with the registrations
below: below:
+---------+------+------------+---------------+ +---------+------+------------+---------------+
| Method | Safe | Idempotent | Reference | | Method | Safe | Idempotent | Reference |
+---------+------+------------+---------------+ +---------+------+------------+---------------+
| CONNECT | no | no | Section 4.3.6 | | CONNECT | no | no | Section 4.3.6 |
| DELETE | no | yes | Section 4.3.5 | | DELETE | no | yes | Section 4.3.5 |
skipping to change at page 73, line 40 skipping to change at page 73, line 44
| PUT | no | yes | Section 4.3.4 | | PUT | no | yes | Section 4.3.4 |
| TRACE | yes | yes | Section 4.3.8 | | TRACE | yes | yes | Section 4.3.8 |
+---------+------+------------+---------------+ +---------+------+------------+---------------+
8.2. Status Code Registry 8.2. Status Code Registry
The HTTP Status Code Registry defines the name space for the response The HTTP Status Code Registry defines the name space for the response
status-code token (Section 6). The status code registry is status-code token (Section 6). The status code registry is
maintained at <http://www.iana.org/assignments/http-status-codes>. maintained at <http://www.iana.org/assignments/http-status-codes>.
This section replaces the registration procedure for HTTP Status This Section replaces the registration procedure for HTTP Status
Codes previously defined in Section 7.1 of [RFC2817]. Codes previously defined in Section 7.1 of [RFC2817].
8.2.1. Procedure 8.2.1. Procedure
A registration MUST include the following fields:
o Status Code (3 digits)
o Short Description
o Pointer to specification text
Values to be added to the HTTP status code name space require IETF Values to be added to the HTTP status code name space require IETF
Review (see [RFC5226], Section 4.1). Review (see [RFC5226], Section 4.1).
8.2.2. Considerations for New Status Codes 8.2.2. Considerations for New Status Codes
When it is necessary to express semantics for a response that are not When it is necessary to express semantics for a response that are not
defined by current status codes, a new status code can be registered. defined by current status codes, a new status code can be registered.
Status codes are generic; they are potentially applicable to any Status codes are generic; they are potentially applicable to any
resource, not just one particular media type, kind of resource, or resource, not just one particular media type, kind of resource, or
application of HTTP. As such, it is preferred that new status codes application of HTTP. As such, it is preferred that new status codes
be registered in a document that isn't specific to a single be registered in a document that isn't specific to a single
application. application.
New status codes are required to fall under one of the categories New status codes are required to fall under one of the categories
defined in Section 6. To allow existing parsers to process the defined in Section 6. To allow existing parsers to process the
response message, new status codes cannot disallow a payload, response message, new status codes cannot disallow a payload,
although they can mandate a zero-length payload body. although they can mandate a zero-length payload body.
skipping to change at page 74, line 37 skipping to change at page 74, line 50
are required, what fields can modify the semantics, and what header are required, what fields can modify the semantics, and what header
field semantics are further refined when used with the new status field semantics are further refined when used with the new status
code). code).
The definition of a new status code ought to specify whether or not The definition of a new status code ought to specify whether or not
it is cacheable. Note that all status codes can be cached if the it is cacheable. Note that all status codes can be cached if the
response they occur in has explicit freshness information; however, response they occur in has explicit freshness information; however,
status codes that are defined as being cacheable are allowed to be status codes that are defined as being cacheable are allowed to be
cached without explicit freshness information. Likewise, the cached without explicit freshness information. Likewise, the
definition of a status code can place constraints upon cache definition of a status code can place constraints upon cache
behaviour. See [Part6] for more information. behavior. See [Part6] for more information.
Finally, the definition of a new status code ought to indicate Finally, the definition of a new status code ought to indicate
whether the payload has any implied association with an identified whether the payload has any implied association with an identified
resource (Section 3.1.4.1). resource (Section 3.1.4.1).
8.2.3. Registrations 8.2.3. Registrations
The HTTP Status Code Registry shall be updated with the registrations The HTTP Status Code Registry shall be updated with the registrations
below: below:
skipping to change at page 77, line 33 skipping to change at page 78, line 33
field's definition not allowing the list syntax. A robust format field's definition not allowing the list syntax. A robust format
enables recipients to discover these situations (good example: enables recipients to discover these situations (good example:
"Content-Type", as the comma can only appear inside quoted "Content-Type", as the comma can only appear inside quoted
strings; bad example: "Location", as a comma can occur inside a strings; bad example: "Location", as a comma can occur inside a
URI). URI).
o Under what conditions the header field can be used; e.g., only in o Under what conditions the header field can be used; e.g., only in
responses or requests, in all messages, only on responses to a responses or requests, in all messages, only on responses to a
particular request method, etc. particular request method, etc.
o Whether the field should be stored by origin servers that
understand it upon a PUT request.
o Whether the field semantics are further refined by the context, o Whether the field semantics are further refined by the context,
such as by existing request methods or status codes. such as by existing request methods or status codes.
o Whether it is appropriate to list the field-name in the Connection o Whether it is appropriate to list the field-name in the Connection
header field (i.e., if the header field is to be hop-by-hop; see header field (i.e., if the header field is to be hop-by-hop; see
Section 6.1 of [Part1]). Section 6.1 of [Part1]).
o Under what conditions intermediaries are allowed to insert, o Under what conditions intermediaries are allowed to insert,
delete, or modify the field's value. delete, or modify the field's value.
o How the header field might interact with caching (see [Part6]). o Whether it is appropriate to list the field-name in a Vary
response header field (e.g., when the request header field is used
by an origin server's content selection algorithm; see
Section 7.1.4).
o Whether the header field is useful or allowable in trailers (see o Whether the header field is useful or allowable in trailers (see
Section 4.1 of [Part1]). Section 4.1 of [Part1]).
o Whether the header field ought to be preserved across redirects. o Whether the header field ought to be preserved across redirects.
8.3.2. Registrations 8.3.2. Registrations
The Message Header Field Registry shall be updated with the following The Message Header Field Registry shall be updated with the following
permanent registrations: permanent registrations:
skipping to change at page 79, line 20 skipping to change at page 80, line 25
Values to be added to this name space require IETF Review (see Values to be added to this name space require IETF Review (see
Section 4.1 of [RFC5226]), and MUST conform to the purpose of content Section 4.1 of [RFC5226]), and MUST conform to the purpose of content
coding defined in this section. coding defined in this section.
8.4.2. Registrations 8.4.2. Registrations
The HTTP Content Codings Registry shall be updated with the The HTTP Content Codings Registry shall be updated with the
registrations below: registrations below:
+----------+----------------------------------------+---------------+ +------------+--------------------------------------+---------------+
| Name | Description | Reference | | Name | Description | Reference |
+----------+----------------------------------------+---------------+ +------------+--------------------------------------+---------------+
| compress | UNIX "compress" program method | Section 4.2.1 | | compress | UNIX "compress" data format [Welch] | Section 4.2.1 |
| | | of [Part1] | | | | of [Part1] |
| deflate | "deflate" compression mechanism | Section 4.2.2 | | deflate | "deflate" compressed data | Section 4.2.2 |
| | ([RFC1951]) used inside the "zlib" | of [Part1] | | | ([RFC1951]) inside the "zlib" data | of [Part1] |
| | data format ([RFC1950]) | | | | format ([RFC1950]) | |
| gzip | Same as GNU zip [RFC1952] | Section 4.2.3 | | gzip | GZIP file format [RFC1952] | Section 4.2.3 |
| | | of [Part1] | | | | of [Part1] |
| identity | reserved (synonym for "no encoding" in | Section 5.3.4 | | identity | Reserved (synonym for "no encoding" | Section 5.3.4 |
| | Accept-Encoding header field) | | | | in Accept-Encoding) | |
+----------+----------------------------------------+---------------+ | x-compress | Deprecated (alias for compress) | Section 4.2.1 |
| | | of [Part1] |
| x-gzip | Deprecated (alias for gzip) | Section 4.2.3 |
| | | of [Part1] |
+------------+--------------------------------------+---------------+
9. Security Considerations 9. Security Considerations
This section is meant to inform developers, information providers, This section is meant to inform developers, information providers,
and users of known security concerns relevant to HTTP/1.1 semantics and users of known security concerns relevant to HTTP/1.1 semantics
and its use for transferring information over the Internet. and its use for transferring information over the Internet.
9.1. Attacks Based On File and Path Names 9.1. Attacks Based On File and Path Names
Origin servers frequently make use of their local file system to Origin servers frequently make use of their local file system to
manage the mapping from effective request URI to resource manage the mapping from effective request URI to resource
representations. Implementors need to be aware that most file representations. Implementers need to be aware that most file
systems are not designed to protect against malicious file or path systems are not designed to protect against malicious file or path
names, and thus depend on the origin server to avoid mapping to file names, and thus depend on the origin server to avoid mapping to file
names, folders, or directories that have special significance to the names, folders, or directories that have special significance to the
system. system.
For example, UNIX, Microsoft Windows, and other operating systems use For example, UNIX, Microsoft Windows, and other operating systems use
".." as a path component to indicate a directory level above the ".." as a path component to indicate a directory level above the
current one, and use specially named paths or file names to send data current one, and use specially named paths or file names to send data
to system devices. Similar naming conventions might exist within to system devices. Similar naming conventions might exist within
other types of storage systems. Likewise, local storage systems have other types of storage systems. Likewise, local storage systems have
skipping to change at page 82, line 43 skipping to change at page 83, line 48
10. Acknowledgments 10. Acknowledgments
See Section 9 of [Part1]. See Section 9 of [Part1].
11. References 11. References
11.1. Normative References 11.1. Normative References
[Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext [Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Message Syntax and Transfer Protocol (HTTP/1.1): Message Syntax and
Routing", draft-ietf-httpbis-p1-messaging-22 (work in Routing", draft-ietf-httpbis-p1-messaging-23 (work in
progress), February 2013. progress), July 2013.
[Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext [Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Conditional Requests", Transfer Protocol (HTTP/1.1): Conditional Requests",
draft-ietf-httpbis-p4-conditional-22 (work in draft-ietf-httpbis-p4-conditional-23 (work in
progress), February 2013. progress), July 2013.
[Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., [Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
"Hypertext Transfer Protocol (HTTP/1.1): Range "Hypertext Transfer Protocol (HTTP/1.1): Range
Requests", draft-ietf-httpbis-p5-range-22 (work in Requests", draft-ietf-httpbis-p5-range-23 (work in
progress), February 2013. progress), July 2013.
[Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
draft-ietf-httpbis-p6-cache-22 (work in progress), draft-ietf-httpbis-p6-cache-23 (work in progress),
February 2013. July 2013.
[Part7] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext [Part7] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Authentication", Transfer Protocol (HTTP/1.1): Authentication",
draft-ietf-httpbis-p7-auth-22 (work in progress), draft-ietf-httpbis-p7-auth-23 (work in progress),
February 2013. July 2013.
[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data
Format Specification version 3.3", RFC 1950, May 1996. Format Specification version 3.3", RFC 1950, May 1996.
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format
Specification version 1.3", RFC 1951, May 1996. Specification version 1.3", RFC 1951, May 1996.
[RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and
G. Randers-Pehrson, "GZIP file format specification G. Randers-Pehrson, "GZIP file format specification
version 4.3", RFC 1952, May 1996. version 4.3", RFC 1952, May 1996.
skipping to change at page 84, line 10 skipping to change at page 85, line 15
January 2008. January 2008.
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for
Identifying Languages", BCP 47, RFC 5646, Identifying Languages", BCP 47, RFC 5646,
September 2009. September 2009.
[RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in
Internationalization in the IETF", BCP 166, RFC 6365, Internationalization in the IETF", BCP 166, RFC 6365,
September 2011. September 2011.
[Welch] Welch, T., "A Technique for High Performance Data
Compression", IEEE Computer 17(6), June 1984.
11.2. Informative References 11.2. Informative References
[BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type [BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13, Specifications and Registration Procedures", BCP 13,
RFC 6838, January 2013. RFC 6838, January 2013.
[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, Procedures for Message Header Fields", BCP 90,
RFC 3864, September 2004. RFC 3864, September 2004.
skipping to change at page 85, line 7 skipping to change at page 86, line 16
form-data", RFC 2388, August 1998. form-data", RFC 2388, August 1998.
[RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud, [RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud,
"MIME Encapsulation of Aggregate Documents, such as "MIME Encapsulation of Aggregate Documents, such as
HTML (MHTML)", RFC 2557, March 1999. HTML (MHTML)", RFC 2557, March 1999.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2774] Frystyk, H., Leach, P., and S. Lawrence, "An HTTP
Extension Framework", RFC 2774, February 2000.
[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within
HTTP/1.1", RFC 2817, May 2000. HTTP/1.1", RFC 2817, May 2000.
[RFC2978] Freed, N. and J. Postel, "IANA Charset Registration [RFC2978] Freed, N. and J. Postel, "IANA Charset Registration
Procedures", BCP 19, RFC 2978, October 2000. Procedures", BCP 19, RFC 2978, October 2000.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26, an IANA Considerations Section in RFCs", BCP 26,
RFC 5226, May 2008. RFC 5226, May 2008.
skipping to change at page 90, line 48 skipping to change at page 92, line 19
absolute-URI = <absolute-URI, defined in [Part1], Section 2.7> absolute-URI = <absolute-URI, defined in [Part1], Section 2.7>
comment = <comment, defined in [Part1], Section 3.2.6> comment = <comment, defined in [Part1], Section 3.2.6>
field-name = <comment, defined in [Part1], Section 3.2> field-name = <comment, defined in [Part1], Section 3.2>
partial-URI = <partial-URI, defined in [Part1], Section 2.7> partial-URI = <partial-URI, defined in [Part1], Section 2.7>
quoted-string = <quoted-string, defined in [Part1], Section 3.2.6> quoted-string = <quoted-string, defined in [Part1], Section 3.2.6>
token = <token, defined in [Part1], Section 3.2.6> token = <token, defined in [Part1], Section 3.2.6>
word = <word, defined in [Part1], Section 3.2.6> word = <word, defined in [Part1], Section 3.2.6>
Appendix D. Collected ABNF Appendix D. Collected ABNF
In the collected ABNF below, list rules are expanded as per Section
1.2 of [Part1].
Accept = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [ Accept = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
OWS ( media-range [ accept-params ] ) ] ) ] OWS ( media-range [ accept-params ] ) ] ) ]
Accept-Charset = *( "," OWS ) ( ( charset / "*" ) [ weight ] ) *( OWS Accept-Charset = *( "," OWS ) ( ( charset / "*" ) [ weight ] ) *( OWS
"," [ OWS ( ( charset / "*" ) [ weight ] ) ] ) "," [ OWS ( ( charset / "*" ) [ weight ] ) ] )
Accept-Encoding = [ ( "," / ( codings [ weight ] ) ) *( OWS "," [ OWS Accept-Encoding = [ ( "," / ( codings [ weight ] ) ) *( OWS "," [ OWS
( codings [ weight ] ) ] ) ] ( codings [ weight ] ) ] ) ]
Accept-Language = *( "," OWS ) ( language-range [ weight ] ) *( OWS Accept-Language = *( "," OWS ) ( language-range [ weight ] ) *( OWS
"," [ OWS ( language-range [ weight ] ) ] ) "," [ OWS ( language-range [ weight ] ) ] )
Allow = [ ( "," / method ) *( OWS "," [ OWS method ] ) ] Allow = [ ( "," / method ) *( OWS "," [ OWS method ] ) ]
BWS = <BWS, defined in [Part1], Section 3.2.3> BWS = <BWS, defined in [Part1], Section 3.2.3>
Content-Encoding = *( "," OWS ) content-coding *( OWS "," [ OWS Content-Encoding = *( "," OWS ) content-coding *( OWS "," [ OWS
content-coding ] ) content-coding ] )
skipping to change at page 94, line 47 skipping to change at page 96, line 17
o <http://tools.ietf.org/wg/httpbis/trac/ticket/428>: "Accept- o <http://tools.ietf.org/wg/httpbis/trac/ticket/428>: "Accept-
Language ordering for identical qvalues" Language ordering for identical qvalues"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/432>: "Identify o <http://tools.ietf.org/wg/httpbis/trac/ticket/432>: "Identify
additional status codes as cacheable by default" additional status codes as cacheable by default"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/434>: "mention in o <http://tools.ietf.org/wg/httpbis/trac/ticket/434>: "mention in
header field considerations that leading/trailing WS is lossy" header field considerations that leading/trailing WS is lossy"
E.3. Since draft-ietf-httpbis-p2-semantics-22
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/436>: "explain list
expansion in ABNF appendices"
o <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/448>: "Fallback
for Accept-Language"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/449>: "Receiving a
higher minor HTTP version number"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/456>: "Language-tag
vs. language-range"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/457>: "Registering
x-gzip and x-deflate"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/459>: "RFC2774 and
method registrations"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/488>: "Selection
based upon request target"
Index Index
1 1
1xx Informational (status code class) 49 1xx Informational (status code class) 49
2 2
2xx Successful (status code class) 50 2xx Successful (status code class) 50
3 3
3xx Redirection (status code class) 53 3xx Redirection (status code class) 53
skipping to change at page 96, line 31 skipping to change at page 98, line 26
C C
cacheable 23 cacheable 23
compress (content coding) 11 compress (content coding) 11
conditional request 36 conditional request 36
CONNECT method 29 CONNECT method 29
content coding 11 content coding 11
content negotiation 6 content negotiation 6
Content-Encoding header field 12 Content-Encoding header field 12
Content-Language header field 13 Content-Language header field 13
Content-Location header field 15 Content-Location header field 15
Content-Transfer-Encoding header field 87 Content-Transfer-Encoding header field 88
Content-Type header field 10 Content-Type header field 10
D D
Date header field 66 Date header field 66
deflate (content coding) 11 deflate (content coding) 11
DELETE method 28 DELETE method 28
E E
Expect header field 33 Expect header field 33
Expect Values Expect Values
skipping to change at page 97, line 48 skipping to change at page 99, line 43
media-range 38 media-range 38
media-type 8 media-type 8
method 20 method 20
minute 64 minute 64
month 64 month 64
obs-date 65 obs-date 65
parameter 8 parameter 8
product 46 product 46
product-version 46 product-version 46
qvalue 37 qvalue 37
Referer 44 Referer 45
Retry-After 68 Retry-After 68
rfc850-date 65 rfc850-date 65
second 64 second 64
Server 71 Server 71
subtype 8 subtype 8
time-of-day 64 time-of-day 64
type 8 type 8
User-Agent 45 User-Agent 46
value 8 value 8
Vary 68 Vary 68
weight 37 weight 37
year 64 year 64
gzip (content coding) 11 gzip (content coding) 11
H H
HEAD method 24 HEAD method 24
I I
idempotent 23 idempotent 23
L L
Location header field 66 Location header field 66
M M
Max-Forwards header field 36 Max-Forwards header field 36
MIME-Version header field 86 MIME-Version header field 87
O O
OPTIONS method 31 OPTIONS method 31
P P
payload 17 payload 17
POST method 25 POST method 25
PUT method 26 PUT method 26
R R
 End of changes. 43 change blocks. 
96 lines changed or deleted 169 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/