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/