| 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.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/