| draft-ietf-httpbis-p3-payload-15.txt |  | draft-ietf-httpbis-p3-payload-16.txt |
--- | --- | --- | --- | ---
| HTTPbis Working Group R. Fielding, Ed. |  | HTTPbis Working Group R. Fielding, Ed. |
| Internet-Draft Adobe |  | Internet-Draft Adobe |
| Obsoletes: 2616 (if approved) J. Gettys |  | Obsoletes: 2616 (if approved) J. Gettys |
| Intended status: Standards Track Alcatel-Lucent |  | Intended status: Standards Track Alcatel-Lucent |
| Expires: January 12, 2012 J. Mogul |  | Expires: February 25, 2012 J. Mogul |
| HP |  | HP |
| H. Frystyk |  | H. Frystyk |
| Microsoft |  | Microsoft |
| L. Masinter |  | L. Masinter |
| Adobe |  | Adobe |
| P. Leach |  | P. Leach |
| Microsoft |  | Microsoft |
| T. Berners-Lee |  | T. Berners-Lee |
| W3C/MIT |  | W3C/MIT |
| Y. Lafon, Ed. |  | Y. Lafon, Ed. |
| W3C |  | W3C |
| J. Reschke, Ed. |  | J. Reschke, Ed. |
| greenbytes |  | greenbytes |
| July 11, 2011 |  | August 24, 2011 |
| HTTP/1.1, part 3: Message Payload and Content Negotiation |  | HTTP/1.1, part 3: Message Payload and Content Negotiation |
| draft-ietf-httpbis-p3-payload-15 |  | draft-ietf-httpbis-p3-payload-16 |
| Abstract |  | Abstract |
| The Hypertext Transfer Protocol (HTTP) is an application-level |  | The Hypertext Transfer Protocol (HTTP) is an application-level |
| protocol for distributed, collaborative, hypermedia information |  | protocol for distributed, collaborative, hypertext information |
| systems. HTTP has been in use by the World Wide Web global |  | systems. HTTP has been in use by the World Wide Web global |
| information initiative since 1990. This document is Part 3 of the |  | information initiative since 1990. This document is Part 3 of the |
| seven-part specification that defines the protocol referred to as |  | seven-part specification that defines the protocol referred to as |
| "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 3 defines |  | "HTTP/1.1" and, taken together, obsoletes RFC 2616. |
| HTTP message content, metadata, and content negotiation. |  |  |
|  |  | Part 3 defines HTTP message content, metadata, and content |
|  |  | negotiation. |
| Editorial Note (To be removed by RFC Editor) |  | Editorial Note (To be removed by RFC Editor) |
| Discussion of this draft should take place on the HTTPBIS working |  | Discussion of this draft should take place on the HTTPBIS working |
| group mailing list (ietf-http-wg@w3.org), which is archived at |  | group 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.16. |  | The changes in this draft are summarized in Appendix E.17. |
| 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 |
| skipping to change at page 2, line 17 |  | skipping to change at page 2, line 20 |
| 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 January 12, 2012. |  | This Internet-Draft will expire on February 25, 2012. |
| Copyright Notice |  | Copyright Notice |
| Copyright (c) 2011 IETF Trust and the persons identified as the |  | Copyright (c) 2011 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 34 |  | skipping to change at page 3, line 36 |
| 6. Header Field Definitions . . . . . . . . . . . . . . . . . . . 16 |  | 6. Header Field Definitions . . . . . . . . . . . . . . . . . . . 16 |
| 6.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . . 16 |  | 6.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . . 16 |
| 6.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . . 18 |  | 6.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . . 18 |
| 6.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 19 |  | 6.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 19 |
| 6.4. Accept-Language . . . . . . . . . . . . . . . . . . . . . 20 |  | 6.4. Accept-Language . . . . . . . . . . . . . . . . . . . . . 20 |
| 6.5. Content-Encoding . . . . . . . . . . . . . . . . . . . . . 21 |  | 6.5. Content-Encoding . . . . . . . . . . . . . . . . . . . . . 21 |
| 6.6. Content-Language . . . . . . . . . . . . . . . . . . . . . 22 |  | 6.6. Content-Language . . . . . . . . . . . . . . . . . . . . . 22 |
| 6.7. Content-Location . . . . . . . . . . . . . . . . . . . . . 23 |  | 6.7. Content-Location . . . . . . . . . . . . . . . . . . . . . 23 |
| 6.8. Content-Type . . . . . . . . . . . . . . . . . . . . . . . 24 |  | 6.8. Content-Type . . . . . . . . . . . . . . . . . . . . . . . 24 |
| 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 |  | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 |
| 7.1. Header Field Registration . . . . . . . . . . . . . . . . 24 |  | 7.1. Header Field Registration . . . . . . . . . . . . . . . . 25 |
| 7.2. Content Coding Registry . . . . . . . . . . . . . . . . . 25 |  | 7.2. Content Coding Registry . . . . . . . . . . . . . . . . . 25 |
| 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 |  | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26 |
| 8.1. Privacy Issues Connected to Accept Header Fields . . . . . 26 |  | 8.1. Privacy Issues Connected to Accept Header Fields . . . . . 26 |
| 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 |  | 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 |
| 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 |  | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 |
| 10.1. Normative References . . . . . . . . . . . . . . . . . . . 26 |  | 10.1. Normative References . . . . . . . . . . . . . . . . . . . 27 |
| 10.2. Informative References . . . . . . . . . . . . . . . . . . 28 |  | 10.2. Informative References . . . . . . . . . . . . . . . . . . 28 |
| Appendix A. Differences between HTTP and MIME . . . . . . . . . . 29 |  | Appendix A. Differences between HTTP and MIME . . . . . . . . . . 30 |
| A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 30 |  | A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 30 |
| A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 30 |  | A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 30 |
| A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 31 |  | A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 31 |
| A.4. Introduction of Content-Encoding . . . . . . . . . . . . . 31 |  | A.4. Introduction of Content-Encoding . . . . . . . . . . . . . 31 |
| A.5. No Content-Transfer-Encoding . . . . . . . . . . . . . . . 31 |  | A.5. No Content-Transfer-Encoding . . . . . . . . . . . . . . . 31 |
| A.6. Introduction of Transfer-Encoding . . . . . . . . . . . . 31 |  | A.6. Introduction of Transfer-Encoding . . . . . . . . . . . . 32 |
| A.7. MHTML and Line Length Limitations . . . . . . . . . . . . 31 |  | A.7. MHTML and Line Length Limitations . . . . . . . . . . . . 32 |
| Appendix B. Additional Features . . . . . . . . . . . . . . . . . 32 |  | Appendix B. Additional Features . . . . . . . . . . . . . . . . . 32 |
| Appendix C. Changes from RFC 2616 . . . . . . . . . . . . . . . . 32 |  | Appendix C. Changes from RFC 2616 . . . . . . . . . . . . . . . . 32 |
| Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 33 |  | Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 33 |
| Appendix E. Change Log (to be removed by RFC Editor before |  | Appendix E. Change Log (to be removed by RFC Editor before |
| publication) . . . . . . . . . . . . . . . . . . . . 34 |  | publication) . . . . . . . . . . . . . . . . . . . . 34 |
| E.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 34 |  | E.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 34 |
| E.2. Since draft-ietf-httpbis-p3-payload-00 . . . . . . . . . . 34 |  | E.2. Since draft-ietf-httpbis-p3-payload-00 . . . . . . . . . . 34 |
| E.3. Since draft-ietf-httpbis-p3-payload-01 . . . . . . . . . . 35 |  | E.3. Since draft-ietf-httpbis-p3-payload-01 . . . . . . . . . . 35 |
| E.4. Since draft-ietf-httpbis-p3-payload-02 . . . . . . . . . . 35 |  | E.4. Since draft-ietf-httpbis-p3-payload-02 . . . . . . . . . . 35 |
| E.5. Since draft-ietf-httpbis-p3-payload-03 . . . . . . . . . . 35 |  | E.5. Since draft-ietf-httpbis-p3-payload-03 . . . . . . . . . . 36 |
| E.6. Since draft-ietf-httpbis-p3-payload-04 . . . . . . . . . . 36 |  | E.6. Since draft-ietf-httpbis-p3-payload-04 . . . . . . . . . . 36 |
| E.7. Since draft-ietf-httpbis-p3-payload-05 . . . . . . . . . . 36 |  | E.7. Since draft-ietf-httpbis-p3-payload-05 . . . . . . . . . . 36 |
| E.8. Since draft-ietf-httpbis-p3-payload-06 . . . . . . . . . . 37 |  | E.8. Since draft-ietf-httpbis-p3-payload-06 . . . . . . . . . . 37 |
| E.9. Since draft-ietf-httpbis-p3-payload-07 . . . . . . . . . . 37 |  | E.9. Since draft-ietf-httpbis-p3-payload-07 . . . . . . . . . . 37 |
| E.10. Since draft-ietf-httpbis-p3-payload-08 . . . . . . . . . . 37 |  | E.10. Since draft-ietf-httpbis-p3-payload-08 . . . . . . . . . . 38 |
| E.11. Since draft-ietf-httpbis-p3-payload-09 . . . . . . . . . . 38 |  | E.11. Since draft-ietf-httpbis-p3-payload-09 . . . . . . . . . . 38 |
| E.12. Since draft-ietf-httpbis-p3-payload-10 . . . . . . . . . . 38 |  | E.12. Since draft-ietf-httpbis-p3-payload-10 . . . . . . . . . . 38 |
| E.13. Since draft-ietf-httpbis-p3-payload-11 . . . . . . . . . . 39 |  | E.13. Since draft-ietf-httpbis-p3-payload-11 . . . . . . . . . . 39 |
| E.14. Since draft-ietf-httpbis-p3-payload-12 . . . . . . . . . . 39 |  | E.14. Since draft-ietf-httpbis-p3-payload-12 . . . . . . . . . . 39 |
| E.15. Since draft-ietf-httpbis-p3-payload-13 . . . . . . . . . . 39 |  | E.15. Since draft-ietf-httpbis-p3-payload-13 . . . . . . . . . . 39 |
| E.16. Since draft-ietf-httpbis-p3-payload-14 . . . . . . . . . . 40 |  | E.16. Since draft-ietf-httpbis-p3-payload-14 . . . . . . . . . . 40 |
|  |  | E.17. Since draft-ietf-httpbis-p3-payload-15 . . . . . . . . . . 40 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 |
| 1. Introduction |  | 1. Introduction |
| This document defines HTTP/1.1 message payloads (a.k.a., content), |  | This document defines HTTP/1.1 message payloads (a.k.a., content), |
| the associated metadata header fields that define how the payload is |  | the associated metadata header fields that define how the payload is |
| intended to be interpreted by a recipient, the request header fields |  | intended to be interpreted by a recipient, the request header fields |
| that might influence content selection, and the various selection |  | that might influence content selection, and the various selection |
| algorithms that are collectively referred to as HTTP content |  | algorithms that are collectively referred to as HTTP content |
| negotiation. |  | negotiation. |
| skipping to change at page 6, line 21 |  | skipping to change at page 6, line 21 |
| The following core rules are included by reference, as defined in |  | The following core rules are included by reference, as defined in |
| [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF |  | [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF |
| (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), |  | (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), |
| HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit |  | HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit |
| sequence of data), SP (space), VCHAR (any visible USASCII character), |  | sequence of data), SP (space), VCHAR (any visible USASCII character), |
| and WSP (whitespace). |  | and WSP (whitespace). |
| 1.3.1. Core Rules |  | 1.3.1. Core Rules |
| The core rules below are defined in Section 1.2.2 of [Part1]: |  | The core rules below are defined in [Part1]: |
| token = <token, defined in [Part1], Section 1.2.2> |  |  |
| word = <word, defined in [Part1], Section 1.2.2> |  |  |
| OWS = <OWS, defined in [Part1], Section 1.2.2> |  | OWS = <OWS, defined in [Part1], Section 1.2.2> |
|  |  | token = <token, defined in [Part1], Section 3.2.3> |
|  |  | word = <word, defined in [Part1], Section 3.2.3> |
| 1.3.2. ABNF Rules defined in other Parts of the Specification |  | 1.3.2. ABNF Rules defined in other Parts of the Specification |
| The ABNF rules below are defined in other parts: |  | The ABNF rules below are defined in other parts: |
| absolute-URI = <absolute-URI, defined in [Part1], Section 2.7> |  | absolute-URI = <absolute-URI, defined in [Part1], Section 2.7> |
| partial-URI = <partial-URI, defined in [Part1], Section 2.7> |  | partial-URI = <partial-URI, defined in [Part1], Section 2.7> |
| qvalue = <qvalue, defined in [Part1], Section 6.4> |  | qvalue = <qvalue, defined in [Part1], Section 6.4> |
| 2. Protocol Parameters |  | 2. Protocol Parameters |
| skipping to change at page 12, line 25 |  | skipping to change at page 12, line 25 |
| The following header fields are defined as representation metadata: |  | The following header fields are defined as representation metadata: |
| +-------------------+------------------------+ |  | +-------------------+------------------------+ |
| | Header Field Name | Defined in... | |  | | Header Field Name | Defined in... | |
| +-------------------+------------------------+ |  | +-------------------+------------------------+ |
| | Content-Encoding | Section 6.5 | |  | | Content-Encoding | Section 6.5 | |
| | Content-Language | Section 6.6 | |  | | Content-Language | Section 6.6 | |
| | Content-Location | Section 6.7 | |  | | Content-Location | Section 6.7 | |
| | Content-Type | Section 6.8 | |  | | Content-Type | Section 6.8 | |
| | Expires | Section 3.3 of [Part6] | |  | | Expires | Section 3.3 of [Part6] | |
| | Last-Modified | Section 2.1 of [Part4] | |  | | Last-Modified | Section 2.2 of [Part4] | |
| +-------------------+------------------------+ |  | +-------------------+------------------------+ |
| 4.2. Representation Data |  | 4.2. Representation Data |
| The representation body associated with an HTTP message is either |  | The representation body associated with an HTTP message is either |
| provided as the payload body of the message or referred to by the |  | provided as the payload body of the message or referred to by the |
| message semantics and the effective request URI. The representation |  | message semantics and the effective request URI. The representation |
| data is in a format and encoding defined by the representation |  | data is in a format and encoding defined by the representation |
| metadata header fields. |  | metadata header fields. |
| skipping to change at page 15, line 8 |  | skipping to change at page 15, line 8 |
| can be both very inefficient (given that only a small percentage |  | can be both very inefficient (given that only a small percentage |
| of responses have multiple representations) and a potential |  | of responses have multiple representations) and a potential |
| violation of the user's privacy. |  | violation of the user's privacy. |
| 3. It complicates the implementation of an origin server and the |  | 3. It complicates the implementation of an origin server and the |
| algorithms for generating responses to a request. |  | algorithms for generating responses to a request. |
| 4. It might limit a public cache's ability to use the same response |  | 4. It might limit a public cache's ability to use the same response |
| for multiple user's requests. |  | for multiple user's requests. |
|  |  | Server-driven negotiation allows the user agent to specify its |
|  |  | preferences, but it cannot expect responses to always honour them. |
|  |  | For example, the origin server might not implement server-driven |
|  |  | negotiation, or it might decide that sending a response that doesn't |
|  |  | conform to them is better than sending a 406 (Not Acceptable) |
|  |  | response. |
|  |  | Many of the mechanisms for expressing preferences use quality values |
|  |  | to declare relative preference. See Section 6.4 of [Part1] for more |
|  |  | information. |
| HTTP/1.1 includes the following header fields for enabling server- |  | HTTP/1.1 includes the following header fields for enabling server- |
| driven negotiation through description of user agent capabilities and |  | driven negotiation through description of user agent capabilities and |
| user preferences: Accept (Section 6.1), Accept-Charset (Section 6.2), |  | user preferences: Accept (Section 6.1), Accept-Charset (Section 6.2), |
| Accept-Encoding (Section 6.3), Accept-Language (Section 6.4), and |  | Accept-Encoding (Section 6.3), Accept-Language (Section 6.4), and |
| User-Agent (Section 9.9 of [Part2]). However, an origin server is |  | User-Agent (Section 9.9 of [Part2]). However, an origin server is |
| not limited to these dimensions and MAY vary the response based on |  | not limited to these dimensions and MAY vary the response based on |
| any aspect of the request, including aspects of the connection (e.g., |  | any aspect of the request, including aspects of the connection (e.g., |
| IP address) or information within extension header fields not defined |  | IP address) or information within extension header fields not defined |
| by this specification. |  | by this specification. |
| skipping to change at page 17, line 4 |  | skipping to change at page 17, line 15 |
| 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". |
| If no Accept header field is present, then it is assumed that the |  | If no Accept header field is present, then it is assumed that the |
| client accepts all media types. If an Accept header field is |  | client accepts all media types. If an Accept header field is present |
| present, and if the server cannot send a response which is acceptable |  | in a request, but the server cannot send a response which is |
| according to the combined Accept field value, then the server SHOULD |  | acceptable, then the server can either send a response in another |
| send a 406 (Not Acceptable) response. |  | format, or a 406 (Not Acceptable) response. |
| 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 preferred media types, but if they do not exist, then send the |  | the preferred media types, but if they do not exist, then send the |
| text/x-dvi representation, and if that does not exist, send the text/ |  | text/x-dvi representation, and if that does not exist, send the text/ |
| plain representation". |  | plain representation". |
| skipping to change at page 18, line 48 |  | skipping to change at page 19, line 8 |
| Accept-Charset: iso-8859-5, unicode-1-1;q=0.8 |  | Accept-Charset: iso-8859-5, unicode-1-1;q=0.8 |
| The special value "*", if present in the Accept-Charset field, |  | The special value "*", if present in the Accept-Charset field, |
| matches every character encoding which is not mentioned elsewhere in |  | matches every character encoding which is not mentioned elsewhere in |
| the Accept-Charset field. If no "*" is present in an Accept-Charset |  | the Accept-Charset field. If no "*" is present in an Accept-Charset |
| field, then all character encodings not explicitly mentioned get a |  | field, then all character encodings not explicitly mentioned get a |
| quality value of 0. |  | quality value of 0. |
| If no Accept-Charset header field is present, the default is that any |  | If no Accept-Charset header field is present, the default is that any |
| character encoding is acceptable. If an Accept-Charset header field |  | character encoding is acceptable. If an Accept-Charset header field |
| is present, and if the server cannot send a response which is |  | is present in a request, but the server cannot send a response which |
| acceptable according to the Accept-Charset header field, then the |  | is acceptable, then the server can either use another character |
| server SHOULD send an error response with the 406 (Not Acceptable) |  | encoding, or send a 406 (Not Acceptable) response. |
| status code, though the sending of an unacceptable response is also |  |  |
| allowed. |  |  |
| 6.3. Accept-Encoding |  | 6.3. 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 2.2) are acceptable |  | indicate what response content-codings (Section 2.2) are acceptable |
| in the response. |  | in the response. |
| Accept-Encoding = #( codings [ OWS ";" OWS "q=" qvalue ] ) |  | Accept-Encoding = #( codings [ OWS ";" OWS "q=" qvalue ] ) |
| codings = ( content-coding / "*" ) |  | codings = ( content-coding / "*" ) |
| skipping to change at page 19, line 48 |  | skipping to change at page 20, line 7 |
| 3. If multiple content-codings are acceptable, then the acceptable |  | 3. If multiple content-codings are acceptable, then the acceptable |
| content-coding with the highest non-zero qvalue is preferred. |  | content-coding with the highest non-zero qvalue is preferred. |
| 4. The "identity" content-coding is always acceptable, unless |  | 4. The "identity" content-coding is always acceptable, unless |
| specifically refused because the Accept-Encoding field includes |  | specifically refused because the Accept-Encoding field includes |
| "identity;q=0", or because the field includes "*;q=0" and does |  | "identity;q=0", or because the field includes "*;q=0" and does |
| not explicitly include the "identity" content-coding. If the |  | not explicitly include the "identity" content-coding. If the |
| Accept-Encoding field-value is empty, then only the "identity" |  | Accept-Encoding field-value is empty, then only the "identity" |
| encoding is acceptable. |  | encoding is acceptable. |
| If an Accept-Encoding field is present in a request, and if the |  | If an Accept-Encoding field is present in a request, but the server |
| server cannot send a response which is acceptable according to the |  | cannot send a response which is acceptable, then the server SHOULD |
| Accept-Encoding header field, then the server SHOULD send an error |  | send a response without any encoding (i.e., the "identity" encoding). |
| response with the 406 (Not Acceptable) status code. |  |  |
| If no Accept-Encoding field is present in a request, the server MAY |  | If no Accept-Encoding field is present in a request, the server MAY |
| assume that the client will accept any content coding. In this case, |  | assume that the client will accept any content coding. In this case, |
| if "identity" is one of the available content-codings, then the |  | if "identity" is one of the available content-codings, then the |
| server SHOULD use the "identity" content-coding, unless it has |  | server SHOULD use the "identity" content-coding, unless it has |
| additional information that a different content-coding is meaningful |  | additional information that a different content-coding is meaningful |
| to the client. |  | to the client. |
| Note: If the request does not include an Accept-Encoding field, |  | Note: If the request does not include an Accept-Encoding field, |
| and if the "identity" content-coding is unavailable, then content- |  | and if the "identity" content-coding is unavailable, then content- |
| skipping to change at page 26, line 42 |  | skipping to change at page 26, line 50 |
| identifier. In environments where proxies are used to enhance |  | identifier. In environments where proxies are used to enhance |
| privacy, user agents ought to be conservative in offering accept |  | privacy, user agents ought to be conservative in offering accept |
| header configuration options to end users. As an extreme privacy |  | header configuration options to end users. As an extreme privacy |
| measure, proxies could filter the accept header fields in relayed |  | measure, proxies could filter the accept header fields in relayed |
| requests. General purpose user agents which provide a high degree of |  | requests. General purpose user agents which provide a high degree of |
| header configurability SHOULD warn users about the loss of privacy |  | header configurability SHOULD warn users about the loss of privacy |
| which can be involved. |  | which can be involved. |
| 9. Acknowledgments |  | 9. Acknowledgments |
| 10. References |  | See Section 12 of [Part1]. |
|  |  | 10. References |
| 10.1. Normative References |  | 10.1. Normative References |
| [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, |  | and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, |
| and Message Parsing", draft-ietf-httpbis-p1-messaging-15 |  | and Message Parsing", draft-ietf-httpbis-p1-messaging-16 |
| (work in progress), July 2011. |  | (work in progress), August 2011. |
| [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| and J. Reschke, Ed., "HTTP/1.1, part 2: Message |  | and J. Reschke, Ed., "HTTP/1.1, part 2: Message |
| Semantics", draft-ietf-httpbis-p2-semantics-15 (work in |  | Semantics", draft-ietf-httpbis-p2-semantics-16 (work in |
| progress), July 2011. |  | progress), August 2011. |
| [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional |  | and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional |
| Requests", draft-ietf-httpbis-p4-conditional-15 (work in |  | Requests", draft-ietf-httpbis-p4-conditional-16 (work in |
| progress), July 2011. |  | progress), August 2011. |
| [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and |  | and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and |
| Partial Responses", draft-ietf-httpbis-p5-range-15 (work |  | Partial Responses", draft-ietf-httpbis-p5-range-16 (work |
| in progress), July 2011. |  | in progress), August 2011. |
| [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part |  | Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part |
| 6: Caching", draft-ietf-httpbis-p6-cache-15 (work in |  | 6: Caching", draft-ietf-httpbis-p6-cache-16 (work in |
| progress), July 2011. |  | progress), August 2011. |
| [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format |  | [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format |
| Specification version 3.3", RFC 1950, May 1996. |  | Specification version 3.3", RFC 1950, May 1996. |
| RFC 1950 is an Informational RFC, thus it might be less |  | RFC 1950 is an Informational RFC, thus it might be less |
| stable than this specification. On the other hand, this |  | stable than this specification. On the other hand, this |
| downward reference was present since the publication of |  | downward reference was present since the publication of |
| RFC 2068 in 1997 ([RFC2068]), therefore it is unlikely to |  | RFC 2068 in 1997 ([RFC2068]), therefore it is unlikely to |
| cause problems in practice. See also [BCP97]. |  | cause problems in practice. See also [BCP97]. |
| skipping to change at page 33, line 52 |  | skipping to change at page 34, line 17 |
| ";" OWS parameter ) |  | ";" OWS parameter ) |
| media-type = type "/" subtype *( OWS ";" OWS parameter ) |  | media-type = type "/" subtype *( OWS ";" OWS parameter ) |
| parameter = attribute "=" value |  | parameter = attribute "=" value |
| partial-URI = <partial-URI, defined in [Part1], Section 2.7> |  | partial-URI = <partial-URI, defined in [Part1], Section 2.7> |
| qvalue = <qvalue, defined in [Part1], Section 6.4> |  | qvalue = <qvalue, defined in [Part1], Section 6.4> |
| subtype = token |  | subtype = token |
| token = <token, defined in [Part1], Section 1.2.2> |  | token = <token, defined in [Part1], Section 3.2.3> |
| type = token |  | type = token |
| value = word |  | value = word |
| word = <word, defined in [Part1], Section 1.2.2> |  | word = <word, defined in [Part1], Section 3.2.3> |
| ABNF diagnostics: |  | ABNF diagnostics: |
| ; Accept defined but not used |  | ; Accept defined but not used |
| ; Accept-Charset defined but not used |  | ; Accept-Charset defined but not used |
| ; Accept-Encoding defined but not used |  | ; Accept-Encoding defined but not used |
| ; Accept-Language defined but not used |  | ; Accept-Language defined but not used |
| ; Content-Encoding defined but not used |  | ; Content-Encoding defined but not used |
| ; Content-Language defined but not used |  | ; Content-Language defined but not used |
| ; Content-Location defined but not used |  | ; Content-Location defined but not used |
| skipping to change at page 40, line 9 |  | skipping to change at page 40, line 21 |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle |
| ABNFs for header fields" |  | ABNFs for header fields" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/281>: "confusing |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/281>: "confusing |
| undefined parameter in media range example" |  | undefined parameter in media range example" |
| E.16. Since draft-ietf-httpbis-p3-payload-14 |  | E.16. Since draft-ietf-httpbis-p3-payload-14 |
| None. |  | None. |
|  |  | E.17. Since draft-ietf-httpbis-p3-payload-15 |
|  |  | Closed issues: |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/285>: "Strength of |
|  |  | requirements on Accept re: 406" |
| Index |  | Index |
| A |  | A |
| Accept header field 16 |  | Accept header field 16 |
| Accept-Charset header field 18 |  | Accept-Charset header field 18 |
| Accept-Encoding header field 19 |  | Accept-Encoding header field 19 |
| Accept-Language header field 20 |  | Accept-Language header field 20 |
| C |  | C |
| Coding Format |  | Coding Format |
End of changes. 35 change blocks.
| 47 lines changed or deleted |  | 69 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/