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/ |