draft-ietf-httpbis-p3-payload-11.txt   draft-ietf-httpbis-p3-payload-12.txt 
HTTPbis Working Group R. Fielding, Ed. HTTPbis Working Group R. Fielding, Ed.
Internet-Draft Day Software Internet-Draft Day Software
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: February 5, 2011 J. Mogul Expires: April 28, 2011 J. Mogul
HP HP
H. Frystyk H. Frystyk
Microsoft Microsoft
L. Masinter L. Masinter
Adobe Systems Adobe Systems
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
August 4, 2010 October 25, 2010
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-11 draft-ietf-httpbis-p3-payload-12
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, hypermedia 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. Part 3 defines
HTTP message content, metadata, and content negotiation. 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). The current issues list is group mailing list (ietf-http-wg@w3.org). The current issues list is
at <http://tools.ietf.org/wg/httpbis/trac/report/3> and related at <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.12. The changes in this draft are summarized in Appendix E.13.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 5, 2011. This Internet-Draft will expire on April 28, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 37 skipping to change at page 3, line 37
6.4. Accept-Language . . . . . . . . . . . . . . . . . . . . . 21 6.4. Accept-Language . . . . . . . . . . . . . . . . . . . . . 21
6.5. Content-Encoding . . . . . . . . . . . . . . . . . . . . . 22 6.5. Content-Encoding . . . . . . . . . . . . . . . . . . . . . 22
6.6. Content-Language . . . . . . . . . . . . . . . . . . . . . 23 6.6. Content-Language . . . . . . . . . . . . . . . . . . . . . 23
6.7. Content-Location . . . . . . . . . . . . . . . . . . . . . 24 6.7. Content-Location . . . . . . . . . . . . . . . . . . . . . 24
6.8. Content-MD5 . . . . . . . . . . . . . . . . . . . . . . . 25 6.8. Content-MD5 . . . . . . . . . . . . . . . . . . . . . . . 25
6.9. Content-Type . . . . . . . . . . . . . . . . . . . . . . . 27 6.9. Content-Type . . . . . . . . . . . . . . . . . . . . . . . 27
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
7.1. Header Field Registration . . . . . . . . . . . . . . . . 27 7.1. Header Field Registration . . . . . . . . . . . . . . . . 27
7.2. Content Coding Registry . . . . . . . . . . . . . . . . . 27 7.2. Content Coding Registry . . . . . . . . . . . . . . . . . 27
8. Security Considerations . . . . . . . . . . . . . . . . . . . 28 8. Security Considerations . . . . . . . . . . . . . . . . . . . 28
8.1. Privacy Issues Connected to Accept Headers . . . . . . . . 28 8.1. Privacy Issues Connected to Accept Header Fields . . . . . 28
8.2. Content-Disposition Issues . . . . . . . . . . . . . . . . 29
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
10.1. Normative References . . . . . . . . . . . . . . . . . . . 29 10.1. Normative References . . . . . . . . . . . . . . . . . . . 29
10.2. Informative References . . . . . . . . . . . . . . . . . . 31 10.2. Informative References . . . . . . . . . . . . . . . . . . 31
Appendix A. Differences between HTTP and MIME . . . . . . . . . . 32 Appendix A. Differences between HTTP and MIME . . . . . . . . . . 32
A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 33 A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 33
A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 33 A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 33
A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 34 A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 33
A.4. Introduction of Content-Encoding . . . . . . . . . . . . . 34 A.4. Introduction of Content-Encoding . . . . . . . . . . . . . 34
A.5. No Content-Transfer-Encoding . . . . . . . . . . . . . . . 34 A.5. No Content-Transfer-Encoding . . . . . . . . . . . . . . . 34
A.6. Introduction of Transfer-Encoding . . . . . . . . . . . . 34 A.6. Introduction of Transfer-Encoding . . . . . . . . . . . . 34
A.7. MHTML and Line Length Limitations . . . . . . . . . . . . 35 A.7. MHTML and Line Length Limitations . . . . . . . . . . . . 34
Appendix B. Additional Features . . . . . . . . . . . . . . . . . 35 Appendix B. Additional Features . . . . . . . . . . . . . . . . . 35
B.1. Content-Disposition . . . . . . . . . . . . . . . . . . . 35 Appendix C. Changes from RFC 2616 . . . . . . . . . . . . . . . . 35
Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 35
Appendix C. Changes from RFC 2616 . . . . . . . . . . . . . . . . 36
Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 36
Appendix E. Change Log (to be removed by RFC Editor before Appendix E. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 38 publication) . . . . . . . . . . . . . . . . . . . . 37
E.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 38 E.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 37
E.2. Since draft-ietf-httpbis-p3-payload-00 . . . . . . . . . . 38 E.2. Since draft-ietf-httpbis-p3-payload-00 . . . . . . . . . . 37
E.3. Since draft-ietf-httpbis-p3-payload-01 . . . . . . . . . . 39 E.3. Since draft-ietf-httpbis-p3-payload-01 . . . . . . . . . . 38
E.4. Since draft-ietf-httpbis-p3-payload-02 . . . . . . . . . . 39 E.4. Since draft-ietf-httpbis-p3-payload-02 . . . . . . . . . . 38
E.5. Since draft-ietf-httpbis-p3-payload-03 . . . . . . . . . . 40 E.5. Since draft-ietf-httpbis-p3-payload-03 . . . . . . . . . . 38
E.6. Since draft-ietf-httpbis-p3-payload-04 . . . . . . . . . . 40 E.6. Since draft-ietf-httpbis-p3-payload-04 . . . . . . . . . . 39
E.7. Since draft-ietf-httpbis-p3-payload-05 . . . . . . . . . . 40 E.7. Since draft-ietf-httpbis-p3-payload-05 . . . . . . . . . . 39
E.8. Since draft-ietf-httpbis-p3-payload-06 . . . . . . . . . . 41 E.8. Since draft-ietf-httpbis-p3-payload-06 . . . . . . . . . . 40
E.9. Since draft-ietf-httpbis-p3-payload-07 . . . . . . . . . . 41 E.9. Since draft-ietf-httpbis-p3-payload-07 . . . . . . . . . . 40
E.10. Since draft-ietf-httpbis-p3-payload-08 . . . . . . . . . . 42 E.10. Since draft-ietf-httpbis-p3-payload-08 . . . . . . . . . . 40
E.11. Since draft-ietf-httpbis-p3-payload-09 . . . . . . . . . . 42 E.11. Since draft-ietf-httpbis-p3-payload-09 . . . . . . . . . . 41
E.12. Since draft-ietf-httpbis-p3-payload-10 . . . . . . . . . . 42 E.12. Since draft-ietf-httpbis-p3-payload-10 . . . . . . . . . . 41
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 E.13. Since draft-ietf-httpbis-p3-payload-11 . . . . . . . . . . 42
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
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.
This document is currently disorganized in order to minimize the This document is currently disorganized in order to minimize the
changes between drafts and enable reviewers to see the smaller errata changes between drafts and enable reviewers to see the smaller errata
changes. The next draft will reorganize the sections to better changes. A future draft will reorganize the sections to better
reflect the content. In particular, the sections on entities will be reflect the content. In particular, the sections on entities will be
renamed payload and moved to the first half of the document, while renamed payload and moved to the first half of the document, while
the sections on content negotiation and associated request header the sections on content negotiation and associated request header
fields will be moved to the second half. The current mess reflects fields will be moved to the second half. The current mess reflects
how widely dispersed these topics and associated requirements had how widely dispersed these topics and associated requirements had
become in [RFC2616]. become in [RFC2616].
1.1. Terminology 1.1. Terminology
This specification uses a number of terms to refer to the roles This specification uses a number of terms to refer to the roles
skipping to change at page 6, line 23 skipping to change at page 6, line 23
[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 Section 1.2.2 of [Part1]:
quoted-string = <quoted-string, defined in [Part1], Section 1.2.2>
token = <token, defined in [Part1], Section 1.2.2> token = <token, defined in [Part1], Section 1.2.2>
word = <word, 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>
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.6> absolute-URI = <absolute-URI, defined in [Part1], Section 2.6>
Content-Length = <Content-Length, defined in [Part1], Section 9.2> Content-Length = <Content-Length, defined in [Part1], Section 9.2>
header-field = <header-field, defined in [Part1], Section 3.2>
partial-URI = <partial-URI, defined in [Part1], Section 2.6> partial-URI = <partial-URI, defined in [Part1], Section 2.6>
qvalue = <qvalue, defined in [Part1], Section 6.4> qvalue = <qvalue, defined in [Part1], Section 6.4>
Last-Modified = <Last-Modified, defined in [Part4], Section 6.6> Last-Modified = <Last-Modified, defined in [Part4], Section 6.6>
Content-Range = <Content-Range, defined in [Part5], Section 5.2> Content-Range = <Content-Range, defined in [Part5], Section 5.2>
Expires = <Expires, defined in [Part6], Section 3.3> Expires = <Expires, defined in [Part6], Section 3.3>
2. Protocol Parameters 2. Protocol Parameters
skipping to change at page 7, line 37 skipping to change at page 7, line 35
charset = token charset = token
Although HTTP allows an arbitrary token to be used as a charset Although HTTP allows an arbitrary token to be used as a charset
value, any token that has a predefined value within the IANA value, any token that has a predefined value within the IANA
Character Set registry MUST represent the character set defined by Character Set registry MUST represent the character set defined by
that registry. Applications SHOULD limit their use of character sets that registry. Applications SHOULD limit their use of character sets
to those defined by the IANA registry. to those defined by the IANA registry.
HTTP uses charset in two contexts: within an Accept-Charset request HTTP uses charset in two contexts: within an Accept-Charset request
header (in which the charset value is an unquoted token) and as the header field (in which the charset value is an unquoted token) and as
value of a parameter in a Content-Type header (within a request or the value of a parameter in a Content-Type header field (within a
response), in which case the parameter value of the charset parameter request or response), in which case the parameter value of the
can be quoted. charset parameter can be quoted.
Implementors need to be aware of IETF character set requirements Implementors need to be aware of IETF character set requirements
[RFC3629] [RFC2277]. [RFC3629] [RFC2277].
2.1.1. Missing Charset 2.1.1. Missing Charset
Some HTTP/1.0 software has interpreted a Content-Type header without Some HTTP/1.0 software has interpreted a Content-Type header field
charset parameter incorrectly to mean "recipient should guess". without charset parameter incorrectly to mean "recipient should
Senders wishing to defeat this behavior MAY include a charset guess". Senders wishing to defeat this behavior MAY include a
parameter even when the charset is ISO-8859-1 ([ISO-8859-1]) and charset parameter even when the charset is ISO-8859-1 ([ISO-8859-1])
SHOULD do so when it is known that it will not confuse the recipient. and SHOULD do so when it is known that it will not confuse the
recipient.
Unfortunately, some older HTTP/1.0 clients did not deal properly with Unfortunately, some older HTTP/1.0 clients did not deal properly with
an explicit charset parameter. HTTP/1.1 recipients MUST respect the an explicit charset parameter. HTTP/1.1 recipients MUST respect the
charset label provided by the sender; and those user agents that have charset label provided by the sender; and those user agents that have
a provision to "guess" a charset MUST use the charset from the a provision to "guess" a charset MUST use the charset from the
content-type field if they support that charset, rather than the content-type field if they support that charset, rather than the
recipient's preference, when initially displaying a document. See recipient's preference, when initially displaying a document. See
Section 2.3.1. Section 2.3.1.
2.2. Content Codings 2.2. Content Codings
skipping to change at page 8, line 48 skipping to change at page 8, line 48
See Section 6.2.2.2 of [Part1]. See Section 6.2.2.2 of [Part1].
gzip gzip
See Section 6.2.2.3 of [Part1]. See Section 6.2.2.3 of [Part1].
identity identity
The default (identity) encoding; the use of no transformation The default (identity) encoding; the use of no transformation
whatsoever. This content-coding is used only in the Accept- whatsoever. This content-coding is used only in the Accept-
Encoding header, and SHOULD NOT be used in the Content-Encoding Encoding header field, and SHOULD NOT be used in the Content-
header. Encoding header field.
2.2.1. Content Coding Registry 2.2.1. Content Coding Registry
The HTTP Content Coding Registry defines the name space for the The HTTP Content Coding Registry defines the name space for the
content coding names. content coding names.
Registrations MUST include the following fields: Registrations MUST include the following fields:
o Name o Name
skipping to change at page 17, line 18 skipping to change at page 17, line 18
server-driven negotiation. server-driven negotiation.
6. Header Field Definitions 6. Header Field Definitions
This section defines the syntax and semantics of HTTP/1.1 header This section defines the syntax and semantics of HTTP/1.1 header
fields related to the payload of messages. fields related to the payload of messages.
6.1. Accept 6.1. Accept
The "Accept" request-header field can be used by user agents to The "Accept" request-header field can be used by user agents to
specify response media types that are acceptable. Accept headers can specify response media types that are acceptable. Accept header
be used to indicate that the request is specifically limited to a fields can be used to indicate that the request is specifically
small set of desired types, as in the case of a request for an in- limited to a small set of desired types, as in the case of a request
line image. for an in-line image.
Accept = "Accept" ":" OWS Accept-v Accept = "Accept" ":" OWS Accept-v
Accept-v = #( media-range [ accept-params ] ) Accept-v = #( media-range [ accept-params ] )
media-range = ( "*/*" media-range = ( "*/*"
/ ( type "/" "*" ) / ( type "/" "*" )
/ ( type "/" subtype ) / ( type "/" subtype )
) *( OWS ";" OWS parameter ) ) *( OWS ";" OWS parameter )
accept-params = OWS ";" OWS "q=" qvalue *( accept-ext ) accept-params = OWS ";" OWS "q=" qvalue *( accept-ext )
accept-ext = OWS ";" OWS token accept-ext = OWS ";" OWS token [ "=" word ]
[ "=" word ]
The asterisk "*" character is used to group media types into ranges, The asterisk "*" character is used to group media types into ranges,
with "*/*" indicating all media types and "type/*" indicating all with "*/*" indicating all media types and "type/*" indicating all
subtypes of that type. The media-range MAY include media type subtypes of that type. The media-range MAY include media type
parameters that are applicable to that range. parameters that are applicable to that range.
Each media-range MAY be followed by one or more accept-params, Each media-range MAY be followed by one or more accept-params,
beginning with the "q" parameter for indicating a relative quality beginning with the "q" parameter for indicating a relative quality
factor. The first "q" parameter (if any) separates the media-range factor. The first "q" parameter (if any) separates the media-range
parameter(s) from the accept-params. Quality factors allow the user parameter(s) from the accept-params. Quality factors allow the user
skipping to change at page 19, line 50 skipping to change at page 19, line 50
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 set (including ISO-8859-1) which is not matches every character set (including ISO-8859-1) which is not
mentioned elsewhere in the Accept-Charset field. If no "*" is mentioned elsewhere in the Accept-Charset field. If no "*" is
present in an Accept-Charset field, then all character sets not present in an Accept-Charset field, then all character sets not
explicitly mentioned get a quality value of 0, except for ISO-8859-1, explicitly mentioned get a quality value of 0, except for ISO-8859-1,
which gets a quality value of 1 if not explicitly mentioned. which gets a quality value of 1 if not explicitly mentioned.
If no Accept-Charset header is present, the default is that any If no Accept-Charset header field is present, the default is that any
character set is acceptable. If an Accept-Charset header is present, character set is acceptable. If an Accept-Charset header field is
and if the server cannot send a response which is acceptable present, and if the server cannot send a response which is acceptable
according to the Accept-Charset header, then the server SHOULD send according to the Accept-Charset header field, then the server SHOULD
an error response with the 406 (Not Acceptable) status code, though send an error response with the 406 (Not Acceptable) status code,
the sending of an unacceptable response is also allowed. though the sending of an unacceptable response is also allowed.
6.3. Accept-Encoding 6.3. Accept-Encoding
The "Accept-Encoding" request-header field can be used by user agents The "Accept-Encoding" request-header field can be used by user agents
to indicate what response content-codings (Section 2.2) are to indicate what response content-codings (Section 2.2) are
acceptable in the response. acceptable in the response.
Accept-Encoding = "Accept-Encoding" ":" OWS Accept-Encoding = "Accept-Encoding" ":" OWS
Accept-Encoding-v Accept-Encoding-v
Accept-Encoding-v = Accept-Encoding-v =
skipping to change at page 21, line 8 skipping to change at page 21, line 8
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, and if the
server cannot send a response which is acceptable according to the server cannot send a response which is acceptable according to the
Accept-Encoding header, then the server SHOULD send an error response Accept-Encoding header field, then the server SHOULD send an error
with the 406 (Not Acceptable) status code. 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 22, line 13 skipping to change at page 22, line 13
other types of English". (see also Section 2.3 of [RFC4647]) other types of English". (see also Section 2.3 of [RFC4647])
For matching, Section 3 of [RFC4647] defines several matching For matching, Section 3 of [RFC4647] defines several matching
schemes. Implementations can offer the most appropriate matching schemes. Implementations can offer the most appropriate matching
scheme for their requirements. scheme for their requirements.
Note: The "Basic Filtering" scheme ([RFC4647], Section 3.3.1) is Note: The "Basic Filtering" scheme ([RFC4647], Section 3.3.1) is
identical to the matching scheme that was previously defined in identical to the matching scheme that was previously defined in
Section 14.4 of [RFC2616]. Section 14.4 of [RFC2616].
It might be contrary to the privacy expectations of the user to send It might be contrary to the privacy expectations of the user to send
an Accept-Language header with the complete linguistic preferences of an Accept-Language header field with the complete linguistic
the user in every request. For a discussion of this issue, see preferences of the user in every request. For a discussion of this
Section 8.1. issue, see Section 8.1.
As intelligibility is highly dependent on the individual user, it is As intelligibility is highly dependent on the individual user, it is
recommended that client applications make the choice of linguistic recommended that client applications make the choice of linguistic
preference available to the user. If the choice is not made preference available to the user. If the choice is not made
available, then the Accept-Language header field MUST NOT be given in available, then the Accept-Language header field MUST NOT be given in
the request. the request.
Note: When making the choice of linguistic preference available to Note: When making the choice of linguistic preference available to
the user, we remind implementors of the fact that users are not the user, we remind implementors of the fact that users are not
familiar with the details of language matching as described above, familiar with the details of language matching as described above,
skipping to change at page 26, line 28 skipping to change at page 26, line 28
decoded prior to checking the Content-MD5 value against the received decoded prior to checking the Content-MD5 value against the received
payload. payload.
HTTP extends RFC 1864 to permit the digest to be computed for MIME HTTP extends RFC 1864 to permit the digest to be computed for MIME
composite media-types (e.g., multipart/* and message/rfc822), but composite media-types (e.g., multipart/* and message/rfc822), but
this does not change how the digest is computed as defined in the this does not change how the digest is computed as defined in the
preceding paragraph. preceding paragraph.
There are several consequences of this. The payload for composite There are several consequences of this. The payload for composite
types MAY contain many body-parts, each with its own MIME and HTTP types MAY contain many body-parts, each with its own MIME and HTTP
headers (including Content-MD5, Content-Transfer-Encoding, and header fields (including Content-MD5, Content-Transfer-Encoding, and
Content-Encoding headers). If a body-part has a Content-Transfer- Content-Encoding header fields). If a body-part has a Content-
Encoding or Content-Encoding header, it is assumed that the content Transfer-Encoding or Content-Encoding header field, it is assumed
of the body-part has had the encoding applied, and the body-part is that the content of the body-part has had the encoding applied, and
included in the Content-MD5 digest as is -- i.e., after the the body-part is included in the Content-MD5 digest as is -- i.e.,
application. The Transfer-Encoding header field is not allowed after the application. The Transfer-Encoding header field is not
within body-parts. allowed within body-parts.
Conversion of all line breaks to CRLF MUST NOT be done before Conversion of all line breaks to CRLF MUST NOT be done before
computing or checking the digest: the line break convention used in computing or checking the digest: the line break convention used in
the text actually transmitted MUST be left unaltered when computing the text actually transmitted MUST be left unaltered when computing
the digest. the digest.
Note: While the definition of Content-MD5 is exactly the same for Note: While the definition of Content-MD5 is exactly the same for
HTTP as in RFC 1864 for MIME entity-bodies, there are several ways HTTP as in RFC 1864 for MIME entity-bodies, there are several ways
in which the application of Content-MD5 to HTTP entity-bodies in which the application of Content-MD5 to HTTP entity-bodies
differs from its application to MIME entity-bodies. One is that differs from its application to MIME entity-bodies. One is that
skipping to change at page 27, line 29 skipping to change at page 27, line 29
Further discussion of Content-Type is provided in Section 4.2. Further discussion of Content-Type is provided in Section 4.2.
7. IANA Considerations 7. IANA Considerations
7.1. Header Field Registration 7.1. Header Field Registration
The Message Header Field Registry located at <http://www.iana.org/ The Message Header Field Registry located at <http://www.iana.org/
assignments/message-headers/message-header-index.html> shall be assignments/message-headers/message-header-index.html> shall be
updated with the permanent registrations below (see [RFC3864]): updated with the permanent registrations below (see [RFC3864]):
+---------------------+----------+----------+--------------+ +-------------------+----------+----------+--------------+
| Header Field Name | Protocol | Status | Reference | | Header Field Name | Protocol | Status | Reference |
+---------------------+----------+----------+--------------+ +-------------------+----------+----------+--------------+
| Accept | http | standard | Section 6.1 | | Accept | http | standard | Section 6.1 |
| Accept-Charset | http | standard | Section 6.2 | | Accept-Charset | http | standard | Section 6.2 |
| Accept-Encoding | http | standard | Section 6.3 | | Accept-Encoding | http | standard | Section 6.3 |
| Accept-Language | http | standard | Section 6.4 | | Accept-Language | http | standard | Section 6.4 |
| Content-Disposition | http | standard | Appendix B.1 | | Content-Encoding | http | standard | Section 6.5 |
| Content-Encoding | http | standard | Section 6.5 | | Content-Language | http | standard | Section 6.6 |
| Content-Language | http | standard | Section 6.6 | | Content-Location | http | standard | Section 6.7 |
| Content-Location | http | standard | Section 6.7 | | Content-MD5 | http | standard | Section 6.8 |
| Content-MD5 | http | standard | Section 6.8 | | Content-Type | http | standard | Section 6.9 |
| Content-Type | http | standard | Section 6.9 | | MIME-Version | http | standard | Appendix A.1 |
| MIME-Version | http | standard | Appendix A.1 | +-------------------+----------+----------+--------------+
+---------------------+----------+----------+--------------+
The change controller is: "IETF (iesg@ietf.org) - Internet The change controller is: "IETF (iesg@ietf.org) - Internet
Engineering Task Force". Engineering Task Force".
7.2. Content Coding Registry 7.2. Content Coding Registry
The registration procedure for HTTP Content Codings is now defined by The registration procedure for HTTP Content Codings is now defined by
Section 2.2.1 of this document. Section 2.2.1 of this document.
The HTTP Content Codings Registry located at The HTTP Content Codings Registry located at
skipping to change at page 28, line 32 skipping to change at page 28, line 30
+----------+-----------------------------------------+--------------+ +----------+-----------------------------------------+--------------+
8. Security Considerations 8. Security Considerations
This section is meant to inform application developers, information This section is meant to inform application developers, information
providers, and users of the security limitations in HTTP/1.1 as providers, and users of the security limitations in HTTP/1.1 as
described by this document. The discussion does not include described by this document. The discussion does not include
definitive solutions to the problems revealed, though it does make definitive solutions to the problems revealed, though it does make
some suggestions for reducing security risks. some suggestions for reducing security risks.
8.1. Privacy Issues Connected to Accept Headers 8.1. Privacy Issues Connected to Accept Header Fields
Accept request-headers can reveal information about the user to all Accept request-headers fields can reveal information about the user
servers which are accessed. The Accept-Language header in particular to all servers which are accessed. The Accept-Language header field
can reveal information the user would consider to be of a private in particular can reveal information the user would consider to be of
nature, because the understanding of particular languages is often a private nature, because the understanding of particular languages
strongly correlated to the membership of a particular ethnic group. is often strongly correlated to the membership of a particular ethnic
User agents which offer the option to configure the contents of an group. User agents which offer the option to configure the contents
Accept-Language header to be sent in every request are strongly of an Accept-Language header field to be sent in every request are
encouraged to let the configuration process include a message which strongly encouraged to let the configuration process include a
makes the user aware of the loss of privacy involved. message which makes the user aware of the loss of privacy involved.
An approach that limits the loss of privacy would be for a user agent An approach that limits the loss of privacy would be for a user agent
to omit the sending of Accept-Language headers by default, and to ask to omit the sending of Accept-Language header fields by default, and
the user whether or not to start sending Accept-Language headers to a to ask the user whether or not to start sending Accept-Language
server if it detects, by looking for any Vary response-header fields header fields to a server if it detects, by looking for any Vary
generated by the server, that such sending could improve the quality response-header fields generated by the server, that such sending
of service. could improve the quality of service.
Elaborate user-customized accept header fields sent in every request, Elaborate user-customized accept header fields sent in every request,
in particular if these include quality values, can be used by servers in particular if these include quality values, can be used by servers
as relatively reliable and long-lived user identifiers. Such user as relatively reliable and long-lived user identifiers. Such user
identifiers would allow content providers to do click-trail tracking, identifiers would allow content providers to do click-trail tracking,
and would allow collaborating content providers to match cross-server and would allow collaborating content providers to match cross-server
click-trails or form submissions of individual users. Note that for click-trails or form submissions of individual users. Note that for
many users not behind a proxy, the network address of the host many users not behind a proxy, the network address of the host
running the user agent will also serve as a long-lived user running the user agent will also serve as a long-lived user
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 headers in relayed requests. measure, proxies could filter the accept header fields in relayed
General purpose user agents which provide a high degree of header requests. General purpose user agents which provide a high degree of
configurability SHOULD warn users about the loss of privacy which can header configurability SHOULD warn users about the loss of privacy
be involved. which can be involved.
8.2. Content-Disposition Issues
[RFC2183], from which the often implemented Content-Disposition (see
Appendix B.1) header in HTTP is derived, has a number of very serious
security considerations. Content-Disposition is not part of the HTTP
standard, but since it is widely implemented, we are documenting its
use and risks for implementors. See Section 5 of [RFC2183] for
details.
9. Acknowledgments 9. Acknowledgments
10. References 10. References
10.1. Normative References 10.1. Normative References
[ISO-8859-1] International Organization for Standardization, [ISO-8859-1] International Organization for Standardization,
"Information technology -- 8-bit single-byte coded "Information technology -- 8-bit single-byte coded
graphic character sets -- Part 1: Latin alphabet No. graphic character sets -- Part 1: Latin alphabet No.
1", ISO/IEC 8859-1:1998, 1998. 1", ISO/IEC 8859-1:1998, 1998.
[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., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
Ed., and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Ed., and J. Reschke, Ed., "HTTP/1.1, part 1: URIs,
Connections, and Message Parsing", Connections, and Message Parsing",
draft-ietf-httpbis-p1-messaging-11 (work in progress), draft-ietf-httpbis-p1-messaging-12 (work in progress),
August 2010. October 2010.
[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., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
Ed., and J. Reschke, Ed., "HTTP/1.1, part 2: Message Ed., and J. Reschke, Ed., "HTTP/1.1, part 2: Message
Semantics", draft-ietf-httpbis-p2-semantics-11 (work in Semantics", draft-ietf-httpbis-p2-semantics-12 (work in
progress), August 2010. progress), October 2010.
[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., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
Ed., and J. Reschke, Ed., "HTTP/1.1, part 4: Ed., and J. Reschke, Ed., "HTTP/1.1, part 4:
Conditional Requests", Conditional Requests",
draft-ietf-httpbis-p4-conditional-11 (work in draft-ietf-httpbis-p4-conditional-12 (work in
progress), August 2010. progress), October 2010.
[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., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
Ed., and J. Reschke, Ed., "HTTP/1.1, part 5: Range Ed., and J. Reschke, Ed., "HTTP/1.1, part 5: Range
Requests and Partial Responses", Requests and Partial Responses",
draft-ietf-httpbis-p5-range-11 (work in progress), draft-ietf-httpbis-p5-range-12 (work in progress),
August 2010. October 2010.
[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., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
Ed., Nottingham, M., Ed., and J. Reschke, Ed., Ed., Nottingham, M., Ed., and J. Reschke, Ed.,
"HTTP/1.1, part 6: Caching", "HTTP/1.1, part 6: Caching",
draft-ietf-httpbis-p6-cache-11 (work in progress), draft-ietf-httpbis-p6-cache-12 (work in progress),
August 2010. October 2010.
[RFC1864] Myers, J. and M. Rose, "The Content-MD5 Header Field", [RFC1864] Myers, J. and M. Rose, "The Content-MD5 Header Field",
RFC 1864, October 1995. RFC 1864, October 1995.
[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data
Format Specification version 3.3", RFC 1950, May 1996. Format Specification version 3.3", RFC 1950, May 1996.
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, stable than this specification. On the other hand,
this downward reference was present since the this downward reference was present since the
skipping to change at page 32, line 5 skipping to change at page 31, line 44
Mail Extensions (MIME) Part Five: Conformance Criteria Mail Extensions (MIME) Part Five: Conformance Criteria
and Examples", RFC 2049, November 1996. and Examples", RFC 2049, November 1996.
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and
T. Berners-Lee, "Hypertext Transfer Protocol -- T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2068, January 1997. HTTP/1.1", RFC 2068, January 1997.
[RFC2076] Palme, J., "Common Internet Message Headers", RFC 2076, [RFC2076] Palme, J., "Common Internet Message Headers", RFC 2076,
February 1997. February 1997.
[RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating
Presentation Information in Internet Messages: The
Content-Disposition Header Field", RFC 2183,
August 1997.
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998. Languages", BCP 18, RFC 2277, January 1998.
[RFC2295] Holtman, K. and A. Mutz, "Transparent Content [RFC2295] Holtman, K. and A. Mutz, "Transparent Content
Negotiation in HTTP", RFC 2295, March 1998. Negotiation in HTTP", RFC 2295, March 1998.
[RFC2388] Masinter, L., "Returning Values from Forms: multipart/ [RFC2388] Masinter, L., "Returning Values from Forms: multipart/
form-data", RFC 2388, August 1998. form-data", RFC 2388, August 1998.
[RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud, [RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud,
"MIME Encapsulation of Aggregate Documents, such as "MIME Encapsulation of Aggregate Documents, such as
HTML (MHTML)", RFC 2557, March 1999. HTML (MHTML)", RFC 2557, March 1999.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 3629, STD 63, November 2003. 10646", STD 63, RFC 3629, November 2003.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, Procedures for Message Header Fields", BCP 90,
RFC 3864, September 2004. RFC 3864, September 2004.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications
and Registration Procedures", BCP 13, RFC 4288, and Registration Procedures", BCP 13, RFC 4288,
December 2005. December 2005.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing
skipping to change at page 35, line 27 skipping to change at page 35, line 16
[RFC1945] and [RFC2068] document protocol elements used by some [RFC1945] and [RFC2068] document protocol elements used by some
existing HTTP implementations, but not consistently and correctly existing HTTP implementations, but not consistently and correctly
across most HTTP/1.1 applications. Implementors are advised to be across most HTTP/1.1 applications. Implementors are advised to be
aware of these features, but cannot rely upon their presence in, or aware of these features, but cannot rely upon their presence in, or
interoperability with, other HTTP/1.1 applications. Some of these interoperability with, other HTTP/1.1 applications. Some of these
describe proposed experimental features, and some describe features describe proposed experimental features, and some describe features
that experimental deployment found lacking that are now addressed in that experimental deployment found lacking that are now addressed in
the base HTTP/1.1 specification. the base HTTP/1.1 specification.
A number of other headers, such as Content-Disposition and Title, A number of other header fields, such as Content-Disposition and
from SMTP and MIME are also often implemented (see [RFC2076]). Title, from SMTP and MIME are also often implemented (see [RFC2076]).
B.1. Content-Disposition
The "Content-Disposition" response-header field has been proposed as
a means for the origin server to suggest a default filename if the
user requests that the content is saved to a file. This usage is
derived from the definition of Content-Disposition in [RFC2183].
content-disposition = "Content-Disposition" ":" OWS
content-disposition-v
content-disposition-v = disposition-type
*( OWS ";" OWS disposition-parm )
disposition-type = "attachment" / disp-extension-token
disposition-parm = filename-parm / disp-extension-parm
filename-parm = "filename" "=" quoted-string
disp-extension-token = token
disp-extension-parm = token "=" word
An example is
Content-Disposition: attachment; filename="fname.ext"
The receiving user agent SHOULD NOT respect any directory path
information present in the filename-parm parameter, which is the only
parameter believed to apply to HTTP implementations at this time.
The filename SHOULD be treated as a terminal component only.
If this header is used in a response with the application/
octet-stream content-type, the implied suggestion is that the user
agent should not display the response, but directly enter a "save
response as..." dialog.
See Section 8.2 for Content-Disposition security issues.
Appendix C. Changes from RFC 2616 Appendix C. Changes from RFC 2616
Clarify contexts that charset is used in. (Section 2.1) Clarify contexts that charset is used in. (Section 2.1)
Remove base URI setting semantics for Content-Location due to poor Remove base URI setting semantics for Content-Location due to poor
implementation support, which was caused by too many broken servers implementation support, which was caused by too many broken servers
emitting bogus Content-Location headers, and also the potentially emitting bogus Content-Location header fields, and also the
undesirable effect of potentially breaking relative links in content- potentially undesirable effect of potentially breaking relative links
negotiated resources. (Section 6.7) in content-negotiated resources. (Section 6.7)
Remove reference to non-existant identity transfer-coding value Remove reference to non-existant identity transfer-coding value
tokens. (Appendix A.5) tokens. (Appendix A.5)
Appendix D. Collected ABNF Appendix D. Collected ABNF
Accept = "Accept:" OWS Accept-v Accept = "Accept:" OWS Accept-v
Accept-Charset = "Accept-Charset:" OWS Accept-Charset-v Accept-Charset = "Accept-Charset:" OWS Accept-Charset-v
Accept-Charset-v = *( "," OWS ) ( charset / "*" ) [ OWS ";" OWS "q=" Accept-Charset-v = *( "," OWS ) ( charset / "*" ) [ OWS ";" OWS "q="
qvalue ] *( OWS "," [ OWS ( charset / "*" ) [ OWS ";" OWS "q=" qvalue ] *( OWS "," [ OWS ( charset / "*" ) [ OWS ";" OWS "q="
skipping to change at page 37, line 28 skipping to change at page 36, line 32
OWS = <OWS, defined in [Part1], Section 1.2.2> OWS = <OWS, defined in [Part1], Section 1.2.2>
absolute-URI = <absolute-URI, defined in [Part1], Section 2.6> absolute-URI = <absolute-URI, defined in [Part1], Section 2.6>
accept-ext = OWS ";" OWS token [ "=" word ] accept-ext = OWS ";" OWS token [ "=" word ]
accept-params = OWS ";" OWS "q=" qvalue *accept-ext accept-params = OWS ";" OWS "q=" qvalue *accept-ext
attribute = token attribute = token
charset = token charset = token
codings = ( content-coding / "*" ) codings = ( content-coding / "*" )
content-coding = token content-coding = token
content-disposition = "Content-Disposition:" OWS
content-disposition-v
content-disposition-v = disposition-type *( OWS ";" OWS
disposition-parm )
disp-extension-parm = token "=" word
disp-extension-token = token
disposition-parm = filename-parm / disp-extension-parm
disposition-type = "attachment" / disp-extension-token
filename-parm = "filename=" quoted-string
header-field = <header-field, defined in [Part1], Section 3.2>
language-range = <language-range, defined in [RFC4647], Section 2.1> language-range = <language-range, defined in [RFC4647], Section 2.1>
language-tag = <Language-Tag, defined in [RFC5646], Section 2.1> language-tag = <Language-Tag, defined in [RFC5646], Section 2.1>
media-range = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS media-range = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS
";" 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.6> partial-URI = <partial-URI, defined in [Part1], Section 2.6>
quoted-string = <quoted-string, defined in [Part1], Section 1.2.2>
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 1.2.2>
type = token type = token
value = word value = word
word = <word, defined in [Part1], Section 1.2.2> word = <word, defined in [Part1], Section 1.2.2>
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
skipping to change at page 38, line 32 skipping to change at page 37, line 22
; 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-Length defined but not used ; Content-Length defined but not used
; Content-Location defined but not used ; Content-Location defined but not used
; Content-MD5 defined but not used ; Content-MD5 defined but not used
; Content-Range defined but not used ; Content-Range defined but not used
; Content-Type defined but not used ; Content-Type defined but not used
; Expires defined but not used ; Expires defined but not used
; Last-Modified defined but not used ; Last-Modified defined but not used
; MIME-Version defined but not used ; MIME-Version defined but not used
; content-disposition defined but not used
; header-field defined but not used
Appendix E. Change Log (to be removed by RFC Editor before publication) Appendix E. Change Log (to be removed by RFC Editor before publication)
E.1. Since RFC2616 E.1. Since RFC 2616
Extracted relevant partitions from [RFC2616]. Extracted relevant partitions from [RFC2616].
E.2. Since draft-ietf-httpbis-p3-payload-00 E.2. Since draft-ietf-httpbis-p3-payload-00
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/8>: "Media Type o <http://tools.ietf.org/wg/httpbis/trac/ticket/8>: "Media Type
Registrations" (<http://purl.org/NET/http-errata#media-reg>) Registrations" (<http://purl.org/NET/http-errata#media-reg>)
skipping to change at page 40, line 5 skipping to change at page 38, line 41
o <http://tools.ietf.org/wg/httpbis/trac/ticket/67>: "Quoting o <http://tools.ietf.org/wg/httpbis/trac/ticket/67>: "Quoting
Charsets" Charsets"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/105>: o <http://tools.ietf.org/wg/httpbis/trac/ticket/105>:
"Classification for Allow header" "Classification for Allow header"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/115>: "missing o <http://tools.ietf.org/wg/httpbis/trac/ticket/115>: "missing
default for qvalue in description of Accept-Encoding" default for qvalue in description of Accept-Encoding"
Ongoing work on IANA Message Header Registration Ongoing work on IANA Message Header Field Registration
(<http://tools.ietf.org/wg/httpbis/trac/ticket/40>): (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>):
o Reference RFC 3984, and update header registrations for headers o Reference RFC 3984, and update header field registrations for
defined in this document. headers defined in this document.
E.5. Since draft-ietf-httpbis-p3-payload-03 E.5. Since draft-ietf-httpbis-p3-payload-03
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/67>: "Quoting o <http://tools.ietf.org/wg/httpbis/trac/ticket/67>: "Quoting
Charsets" Charsets"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/113>: "language tag o <http://tools.ietf.org/wg/httpbis/trac/ticket/113>: "language tag
matching (Accept-Language) vs RFC4647" matching (Accept-Language) vs RFC4647"
skipping to change at page 40, line 46 skipping to change at page 39, line 33
Ongoing work on ABNF conversion Ongoing work on ABNF conversion
(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
o Use "/" instead of "|" for alternatives. o Use "/" instead of "|" for alternatives.
o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
whitespace ("OWS") and required whitespace ("RWS"). whitespace ("OWS") and required whitespace ("RWS").
o Rewrite ABNFs to spell out whitespace rules, factor out header o Rewrite ABNFs to spell out whitespace rules, factor out header
value format definitions. field value format definitions.
E.7. Since draft-ietf-httpbis-p3-payload-05 E.7. Since draft-ietf-httpbis-p3-payload-05
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/118>: "Join o <http://tools.ietf.org/wg/httpbis/trac/ticket/118>: "Join
"Differences Between HTTP Entities and RFC 2045 Entities"?" "Differences Between HTTP Entities and RFC 2045 Entities"?"
Final work on ABNF conversion Final work on ABNF conversion
(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
skipping to change at page 43, line 28 skipping to change at page 42, line 13
resource' in content-encoding definition" resource' in content-encoding definition"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider o <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider
removing the 'changes from 2068' sections" removing the 'changes from 2068' sections"
Partly resolved issues: Partly resolved issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/178>: "Content-MD5 o <http://tools.ietf.org/wg/httpbis/trac/ticket/178>: "Content-MD5
and partial responses" and partial responses"
E.13. Since draft-ietf-httpbis-p3-payload-11
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/123>: "Factor out
Content-Disposition"
Index Index
A A
Accept header 17 Accept header 17
Accept-Charset header 19 Accept-Charset header 19
Accept-Encoding header 20 Accept-Encoding header 20
Accept-Language header 21 Accept-Language header 21
C C
Coding Format Coding Format
compress 8 compress 8
deflate 8 deflate 8
gzip 8 gzip 8
identity 8 identity 8
compress (Coding Format) 8 compress (Coding Format) 8
content negotiation 5 content negotiation 5
Content-Disposition header 35
Content-Encoding header 22 Content-Encoding header 22
Content-Language header 23 Content-Language header 23
Content-Location header 24 Content-Location header 24
Content-MD5 header 25 Content-MD5 header 25
Content-Type header 27 Content-Type header 27
D D
deflate (Coding Format) 8 deflate (Coding Format) 8
G G
skipping to change at page 44, line 21 skipping to change at page 43, line 12
Accept-Encoding-v 20 Accept-Encoding-v 20
accept-ext 17 accept-ext 17
Accept-Language 21 Accept-Language 21
Accept-Language-v 21 Accept-Language-v 21
accept-params 17 accept-params 17
Accept-v 17 Accept-v 17
attribute 9 attribute 9
charset 7 charset 7
codings 20 codings 20
content-coding 8 content-coding 8
content-disposition 35
content-disposition-v 35
Content-Encoding 22 Content-Encoding 22
Content-Encoding-v 22 Content-Encoding-v 22
Content-Language 23 Content-Language 23
Content-Language-v 23 Content-Language-v 23
Content-Location 24 Content-Location 24
Content-Location-v 24 Content-Location-v 24
Content-MD5 25 Content-MD5 25
Content-MD5-v 25 Content-MD5-v 25
Content-Type 27 Content-Type 27
Content-Type-v 27 Content-Type-v 27
disp-extension-parm 35
disp-extension-token 35
disposition-parm 35
disposition-type 35
filename-parm 35
language-range 21 language-range 21
language-tag 11 language-tag 11
media-range 17 media-range 17
media-type 9 media-type 9
MIME-Version 33 MIME-Version 33
MIME-Version-v 33 MIME-Version-v 33
parameter 9 parameter 9
subtype 9 subtype 9
type 9 type 9
value 9 value 9
gzip (Coding Format) 8 gzip (Coding Format) 8
H H
Headers Headers
Accept 17 Accept 17
Accept-Charset 19 Accept-Charset 19
Accept-Encoding 20 Accept-Encoding 20
Accept-Language 21 Accept-Language 21
Content-Disposition 35
Content-Encoding 22 Content-Encoding 22
Content-Language 23 Content-Language 23
Content-Location 24 Content-Location 24
Content-MD5 25 Content-MD5 25
Content-Type 27 Content-Type 27
MIME-Version 33 MIME-Version 33
I I
identity (Coding Format) 8 identity (Coding Format) 8
 End of changes. 49 change blocks. 
193 lines changed or deleted 123 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/