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