draft-ietf-httpbis-p3-payload-12.txt   draft-ietf-httpbis-p3-payload-13.txt 
HTTPbis Working Group R. Fielding, Ed. HTTPbis Working Group R. Fielding, Ed.
Internet-Draft Day Software 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: April 28, 2011 J. Mogul Expires: September 15, 2011 J. Mogul
HP HP
H. Frystyk H. Frystyk
Microsoft Microsoft
L. Masinter L. Masinter
Adobe Systems 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
October 25, 2010 March 14, 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-12 draft-ietf-httpbis-p3-payload-13
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.13. The changes in this draft are summarized in Appendix E.14.
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 April 28, 2011. This Internet-Draft will expire on September 15, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 6 skipping to change at page 3, line 6
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 1.3. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6
1.3.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 6 1.3.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 6
1.3.2. ABNF Rules defined in other Parts of the 1.3.2. ABNF Rules defined in other Parts of the
Specification . . . . . . . . . . . . . . . . . . . . 6 Specification . . . . . . . . . . . . . . . . . . . . 6
2. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 6 2. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 6
2.1. Character Sets . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Character Encodings (charset) . . . . . . . . . . . . . . 6
2.1.1. Missing Charset . . . . . . . . . . . . . . . . . . . 7 2.1.1. Missing Charset . . . . . . . . . . . . . . . . . . . 7
2.2. Content Codings . . . . . . . . . . . . . . . . . . . . . 8 2.2. Content Codings . . . . . . . . . . . . . . . . . . . . . 7
2.2.1. Content Coding Registry . . . . . . . . . . . . . . . 9 2.2.1. Content Coding Registry . . . . . . . . . . . . . . . 8
2.3. Media Types . . . . . . . . . . . . . . . . . . . . . . . 9 2.3. Media Types . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.1. Canonicalization and Text Defaults . . . . . . . . . . 10 2.3.1. Canonicalization and Text Defaults . . . . . . . . . . 9
2.3.2. Multipart Types . . . . . . . . . . . . . . . . . . . 11 2.3.2. Multipart Types . . . . . . . . . . . . . . . . . . . 10
2.4. Language Tags . . . . . . . . . . . . . . . . . . . . . . 11 2.4. Language Tags . . . . . . . . . . . . . . . . . . . . . . 10
3. Payload . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3. Payload . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Payload Header Fields . . . . . . . . . . . . . . . . . . 12 3.1. Payload Header Fields . . . . . . . . . . . . . . . . . . 11
3.2. Payload Body . . . . . . . . . . . . . . . . . . . . . . . 12 3.2. Payload Body . . . . . . . . . . . . . . . . . . . . . . . 12
4. Representation . . . . . . . . . . . . . . . . . . . . . . . . 12 4. Representation . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Representation Header Fields . . . . . . . . . . . . . . . 13 4.1. Representation Header Fields . . . . . . . . . . . . . . . 12
4.2. Representation Data . . . . . . . . . . . . . . . . . . . 13 4.2. Representation Data . . . . . . . . . . . . . . . . . . . 13
5. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 14 5. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 14
5.1. Server-driven Negotiation . . . . . . . . . . . . . . . . 15 5.1. Server-driven Negotiation . . . . . . . . . . . . . . . . 15
5.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . . 16 5.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . . 16
6. Header Field Definitions . . . . . . . . . . . . . . . . . . . 17 6. Header Field Definitions . . . . . . . . . . . . . . . . . . . 16
6.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . . 19 6.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . . 19
6.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 20 6.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 19
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 . . . . . . . . . . . . . . . . . . . . . . . 26
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 Header Fields . . . . . 28 8.1. Privacy Issues Connected to Accept Header Fields . . . . . 28
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 . . . . . . . . . . . . . . . . . . . . . . . 32
A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 33 A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 33
A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 33 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 . . . . . . . . . . . . 34 A.7. MHTML and Line Length Limitations . . . . . . . . . . . . 34
Appendix B. Additional Features . . . . . . . . . . . . . . . . . 35 Appendix B. Additional Features . . . . . . . . . . . . . . . . . 34
Appendix C. Changes from RFC 2616 . . . . . . . . . . . . . . . . 35 Appendix C. Changes from RFC 2616 . . . . . . . . . . . . . . . . 35
Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 35 Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 35
Appendix E. Change Log (to be removed by RFC Editor before Appendix E. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 37 publication) . . . . . . . . . . . . . . . . . . . . 37
E.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 37 E.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 37
E.2. Since draft-ietf-httpbis-p3-payload-00 . . . . . . . . . . 37 E.2. Since draft-ietf-httpbis-p3-payload-00 . . . . . . . . . . 37
E.3. Since draft-ietf-httpbis-p3-payload-01 . . . . . . . . . . 38 E.3. Since draft-ietf-httpbis-p3-payload-01 . . . . . . . . . . 38
E.4. Since draft-ietf-httpbis-p3-payload-02 . . . . . . . . . . 38 E.4. Since draft-ietf-httpbis-p3-payload-02 . . . . . . . . . . 38
E.5. Since draft-ietf-httpbis-p3-payload-03 . . . . . . . . . . 38 E.5. Since draft-ietf-httpbis-p3-payload-03 . . . . . . . . . . 38
E.6. Since draft-ietf-httpbis-p3-payload-04 . . . . . . . . . . 39 E.6. Since draft-ietf-httpbis-p3-payload-04 . . . . . . . . . . 39
E.7. Since draft-ietf-httpbis-p3-payload-05 . . . . . . . . . . 39 E.7. Since draft-ietf-httpbis-p3-payload-05 . . . . . . . . . . 39
E.8. Since draft-ietf-httpbis-p3-payload-06 . . . . . . . . . . 40 E.8. Since draft-ietf-httpbis-p3-payload-06 . . . . . . . . . . 39
E.9. Since draft-ietf-httpbis-p3-payload-07 . . . . . . . . . . 40 E.9. Since draft-ietf-httpbis-p3-payload-07 . . . . . . . . . . 40
E.10. Since draft-ietf-httpbis-p3-payload-08 . . . . . . . . . . 40 E.10. Since draft-ietf-httpbis-p3-payload-08 . . . . . . . . . . 40
E.11. Since draft-ietf-httpbis-p3-payload-09 . . . . . . . . . . 41 E.11. Since draft-ietf-httpbis-p3-payload-09 . . . . . . . . . . 41
E.12. Since draft-ietf-httpbis-p3-payload-10 . . . . . . . . . . 41 E.12. Since draft-ietf-httpbis-p3-payload-10 . . . . . . . . . . 41
E.13. Since draft-ietf-httpbis-p3-payload-11 . . . . . . . . . . 42 E.13. Since draft-ietf-httpbis-p3-payload-11 . . . . . . . . . . 42
E.14. Since draft-ietf-httpbis-p3-payload-12 . . . . . . . . . . 42
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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.
skipping to change at page 6, line 32 skipping to change at page 6, line 32
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>
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>
Content-Range = <Content-Range, defined in [Part5], Section 5.2>
Expires = <Expires, defined in [Part6], Section 3.3>
2. Protocol Parameters 2. Protocol Parameters
2.1. Character Sets 2.1. Character Encodings (charset)
HTTP uses the same definition of the term "character set" as that
described for MIME:
The term "character set" is used in this document to refer to a
method used with one or more tables to convert a sequence of octets
into a sequence of characters. Note that unconditional conversion in
the other direction is not required, in that not all characters might
be available in a given character set and a character set might
provide more than one sequence of octets to represent a particular
character. This definition is intended to allow various kinds of
character encoding, from simple single-table mappings such as US-
ASCII to complex table switching methods such as those that use ISO-
2022's techniques. However, the definition associated with a MIME
character set name MUST fully specify the mapping to be performed
from octets to characters. In particular, use of external profiling
information to determine the exact mapping is not permitted.
Note: This use of the term "character set" is more commonly HTTP uses charset names to indicate the character encoding of a
referred to as a "character encoding". However, since HTTP and textual representation.
MIME share the same registry, it is important that the terminology
also be shared.
HTTP character sets are identified by case-insensitive tokens. The A character encoding is identified by a case-insensitive token. The
complete set of tokens is defined by the IANA Character Set registry complete set of tokens is defined by the IANA Character Set registry
(<http://www.iana.org/assignments/character-sets>). (<http://www.iana.org/assignments/character-sets>).
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 encoding defined
that registry. Applications SHOULD limit their use of character sets by that registry. Applications SHOULD limit their use of character
to those defined by the IANA registry. encodings to those defined within 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 field (in which the charset value is an unquoted token) and as header field (in which the charset value is an unquoted token) and as
the value of a parameter in a Content-Type header field (within a the value of a parameter in a Content-Type header field (within a
request or response), in which case the parameter value of the request or response), in which case the parameter value of the
charset parameter 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].
skipping to change at page 9, line 40 skipping to change at page 9, line 9
2.3. Media Types 2.3. Media Types
HTTP uses Internet Media Types [RFC2046] in the Content-Type HTTP uses Internet Media Types [RFC2046] in the Content-Type
(Section 6.9) and Accept (Section 6.1) header fields in order to (Section 6.9) and Accept (Section 6.1) header fields in order to
provide open and extensible data typing and type negotiation. provide open and extensible data typing and type negotiation.
media-type = type "/" subtype *( OWS ";" OWS parameter ) media-type = type "/" subtype *( OWS ";" OWS parameter )
type = token type = token
subtype = token subtype = token
Parameters MAY follow the type/subtype in the form of attribute/value The type/subtype MAY be followed by parameters in the form of
pairs. attribute/value pairs.
parameter = attribute "=" value parameter = attribute "=" value
attribute = token attribute = token
value = word value = word
The type, subtype, and parameter attribute names are case- The type, subtype, and parameter attribute names are case-
insensitive. Parameter values might or might not be case-sensitive, insensitive. Parameter values might or might not be case-sensitive,
depending on the semantics of the parameter name. The presence or depending on the semantics of the parameter name. The presence or
absence of a parameter might be significant to the processing of a absence of a parameter might be significant to the processing of a
media-type, depending on its definition within the media type media-type, depending on its definition within the media type
skipping to change at page 12, line 28 skipping to change at page 11, line 44
header fields (e.g., responses to HEAD) or only some part(s) of the header fields (e.g., responses to HEAD) or only some part(s) of the
representation (e.g., the 206 status code). representation (e.g., the 206 status code).
3.1. Payload Header Fields 3.1. Payload Header Fields
HTTP header fields that specifically define the payload, rather than HTTP header fields that specifically define the payload, rather than
the associated representation, are referred to as "payload header the associated representation, are referred to as "payload header
fields". The following payload header fields are defined by fields". The following payload header fields are defined by
HTTP/1.1: HTTP/1.1:
Content-Length ; [Part1], Section 9.2 +-------------------+------------------------+
Content-MD5 ; Section 6.8 | Header Field Name | Defined in... |
Content-Range ; [Part5], Section 5.2 +-------------------+------------------------+
| Content-Length | Section 9.2 of [Part1] |
| Content-MD5 | Section 6.8 |
| Content-Range | Section 5.2 of [Part5] |
+-------------------+------------------------+
3.2. Payload Body 3.2. Payload Body
A payload body is only present in a message when a message-body is A payload body is only present in a message when a message-body is
present, as described in Section 3.3 of [Part1]. The payload body is present, as described in Section 3.3 of [Part1]. The payload body is
obtained from the message-body by decoding any Transfer-Encoding that obtained from the message-body by decoding any Transfer-Encoding that
might have been applied to ensure safe and proper transfer of the might have been applied to ensure safe and proper transfer of the
message. message.
4. Representation 4. Representation
skipping to change at page 13, line 24 skipping to change at page 13, line 5
4.1. Representation Header Fields 4.1. Representation Header Fields
Representation header fields define metadata about the representation Representation header fields define metadata about the representation
data enclosed in the message-body or, if no message-body is present, data enclosed in the message-body or, if no message-body is present,
about the representation that would have been transferred in a 200 about the representation that would have been transferred in a 200
response to a simultaneous GET request with the same effective response to a simultaneous GET request with the same effective
request URI. request URI.
The following header fields are defined as representation metadata: The following header fields are defined as representation metadata:
Content-Encoding ; Section 6.5 +-------------------+------------------------+
Content-Language ; Section 6.6 | Header Field Name | Defined in... |
Content-Location ; Section 6.7 +-------------------+------------------------+
Content-Type ; Section 6.9 | Content-Encoding | Section 6.5 |
Expires ; [Part6], Section 3.3 | Content-Language | Section 6.6 |
Last-Modified ; [Part4], Section 6.6 | Content-Location | Section 6.7 |
| Content-Type | Section 6.9 |
| Expires | Section 3.3 of [Part6] |
| Last-Modified | Section 6.6 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.
The data type of the representation data is determined via the header The data type of the representation data is determined via the header
skipping to change at page 16, line 11 skipping to change at page 15, line 44
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.
HTTP/1.1 includes the following request-header fields for enabling HTTP/1.1 includes the following header fields for enabling server-
server-driven negotiation through description of user agent driven negotiation through description of user agent capabilities and
capabilities and user preferences: Accept (Section 6.1), Accept- user preferences: Accept (Section 6.1), Accept-Charset (Section 6.2),
Charset (Section 6.2), Accept-Encoding (Section 6.3), Accept-Language Accept-Encoding (Section 6.3), Accept-Language (Section 6.4), and
(Section 6.4), and User-Agent (Section 9.9 of [Part2]). However, an User-Agent (Section 9.9 of [Part2]). However, an origin server is
origin server is not limited to these dimensions and MAY vary the not limited to these dimensions and MAY vary the response based on
response based on any aspect of the request, including information any aspect of the request, including aspects of the connection (e.g.,
outside the request-header fields or within extension header fields IP address) or information within extension header fields not defined
not defined by this specification. by this specification.
Note: In practice, User-Agent based negotiation is fragile, Note: In practice, User-Agent based negotiation is fragile,
because new clients might not be recognized. because new clients might not be recognized.
The Vary header field (Section 3.5 of [Part6]) can be used to express The Vary header field (Section 3.5 of [Part6]) can be used to express
the parameters the server uses to select a representation that is the parameters the server uses to select a representation that is
subject to server-driven negotiation. subject to server-driven negotiation.
5.2. Agent-driven Negotiation 5.2. Agent-driven Negotiation
skipping to change at page 17, line 17 skipping to change at page 16, line 50
the server is unwilling or unable to provide a varying response using the server is unwilling or unable to provide a varying response using
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" header field can be used by user agents to specify
specify response media types that are acceptable. Accept header response media types that are acceptable. Accept header fields can
fields can be used to indicate that the request is specifically be used to indicate that the request is specifically limited to a
limited to a small set of desired types, as in the case of a request small set of desired types, as in the case of a request for an in-
for an in-line image. 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 [ "=" word ] accept-ext = OWS ";" OWS token [ "=" word ]
skipping to change at page 19, line 25 skipping to change at page 19, line 9
| text/html;level=3 | 0.7 | | text/html;level=3 | 0.7 |
+-------------------+---------------+ +-------------------+---------------+
Note: A user agent might be provided with a default set of quality Note: A user agent might be provided with a default set of quality
values for certain media ranges. However, unless the user agent is a values for certain media ranges. However, unless the user agent is a
closed system which cannot interact with other rendering agents, this closed system which cannot interact with other rendering agents, this
default set ought to be configurable by the user. default set ought to be configurable by the user.
6.2. Accept-Charset 6.2. Accept-Charset
The "Accept-Charset" request-header field can be used by user agents The "Accept-Charset" header field can be used by user agents to
to indicate what response character sets are acceptable. This field indicate what character encodings are acceptable in a response
allows clients capable of understanding more comprehensive or payload. This field allows clients capable of understanding more
special-purpose character sets to signal that capability to a server comprehensive or special-purpose character encodings to signal that
which is capable of representing documents in those character sets. capability to a server which is capable of representing documents in
those character encodings.
Accept-Charset = "Accept-Charset" ":" OWS Accept-Charset = "Accept-Charset" ":" OWS
Accept-Charset-v Accept-Charset-v
Accept-Charset-v = 1#( ( charset / "*" ) Accept-Charset-v = 1#( ( charset / "*" )
[ OWS ";" OWS "q=" qvalue ] ) [ OWS ";" OWS "q=" qvalue ] )
Character set values are described in Section 2.1. Each charset MAY Character encoding values (a.k.a., charsets) are described in
be given an associated quality value which represents the user's Section 2.1. Each charset MAY be given an associated quality value
preference for that charset. The default value is q=1. An example which represents the user's preference for that charset. The default
is value is q=1. An example is
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 encoding (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 encodings 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 field 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 field is character encoding is acceptable. If an Accept-Charset header field
present, and if the server cannot send a response which is acceptable is present, and if the server cannot send a response which is
according to the Accept-Charset header field, then the server SHOULD acceptable according to the Accept-Charset header field, then the
send an error response with the 406 (Not Acceptable) status code, server SHOULD send an error response with the 406 (Not Acceptable)
though the sending of an unacceptable response is also allowed. status code, 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" header field can be used by user agents to
to indicate what response content-codings (Section 2.2) are indicate what response content-codings (Section 2.2) are acceptable
acceptable in the response. 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 =
#( codings [ OWS ";" OWS "q=" qvalue ] ) #( codings [ OWS ";" OWS "q=" qvalue ] )
codings = ( content-coding / "*" ) codings = ( content-coding / "*" )
Each codings value MAY be given an associated quality value which Each codings value MAY be given an associated quality value which
represents the preference for that encoding. The default value is represents the preference for that encoding. The default value is
q=1. q=1.
skipping to change at page 21, line 32 skipping to change at page 21, line 22
messages sent with other content-codings. The server might also messages sent with other content-codings. The server might also
make this decision based on information about the particular user- make this decision based on information about the particular user-
agent or client. agent or client.
Note: Most HTTP/1.0 applications do not recognize or obey qvalues Note: Most HTTP/1.0 applications do not recognize or obey qvalues
associated with content-codings. This means that qvalues will not associated with content-codings. This means that qvalues will not
work and are not permitted with x-gzip or x-compress. work and are not permitted with x-gzip or x-compress.
6.4. Accept-Language 6.4. Accept-Language
The "Accept-Language" request-header field can be used by user agents The "Accept-Language" header field can be used by user agents to
to indicate the set of natural languages that are preferred in the indicate the set of natural languages that are preferred in the
response. Language tags are defined in Section 2.4. response. Language tags are defined in Section 2.4.
Accept-Language = "Accept-Language" ":" OWS Accept-Language = "Accept-Language" ":" OWS
Accept-Language-v Accept-Language-v
Accept-Language-v = Accept-Language-v =
1#( language-range [ OWS ";" OWS "q=" qvalue ] ) 1#( language-range [ OWS ";" OWS "q=" qvalue ] )
language-range = language-range =
<language-range, defined in [RFC4647], Section 2.1> <language-range, defined in [RFC4647], Section 2.1>
Each language-range can be given an associated quality value which Each language-range can be given an associated quality value which
skipping to change at page 22, line 50 skipping to change at page 22, line 41
Content-Encoding = "Content-Encoding" ":" OWS Content-Encoding-v Content-Encoding = "Content-Encoding" ":" OWS Content-Encoding-v
Content-Encoding-v = 1#content-coding Content-Encoding-v = 1#content-coding
Content codings are defined in Section 2.2. An example of its use is Content codings are defined in Section 2.2. An example of its use is
Content-Encoding: gzip Content-Encoding: gzip
The content-coding is a characteristic of the representation. The content-coding is a characteristic of the representation.
Typically, the representation body is stored with this encoding and Typically, the representation body is stored with this encoding and
is only decoded before rendering or analogous usage. However, a non- is only decoded before rendering or analogous usage. However, a
transparent proxy MAY modify the content-coding if the new coding is transforming proxy MAY modify the content-coding if the new coding is
known to be acceptable to the recipient, unless the "no-transform" known to be acceptable to the recipient, unless the "no-transform"
cache-control directive is present in the message. cache-control directive is present in the message.
If the content-coding of a representation is not "identity", then the If the content-coding of a representation is not "identity", then the
representation metadata MUST include a Content-Encoding header field representation metadata MUST include a Content-Encoding header field
(Section 6.5) that lists the non-identity content-coding(s) used. (Section 6.5) that lists the non-identity content-coding(s) used.
If the content-coding of a representation in a request message is not If the content-coding of a representation in a request message is not
acceptable to the origin server, the server SHOULD respond with a acceptable to the origin server, the server SHOULD respond with a
status code of 415 (Unsupported Media Type). status code of 415 (Unsupported Media Type).
skipping to change at page 24, line 37 skipping to change at page 24, line 30
It has the same syntax and semantics as the header field of the same It has the same syntax and semantics as the header field of the same
name defined for MIME body parts in Section 4 of [RFC2557]. However, name defined for MIME body parts in Section 4 of [RFC2557]. However,
its appearance in an HTTP message has some special implications for its appearance in an HTTP message has some special implications for
HTTP recipients. HTTP recipients.
If Content-Location is included in a response message and its value If Content-Location is included in a response message and its value
is the same as the effective request URI, then the response payload is the same as the effective request URI, then the response payload
SHOULD be considered the current representation of that resource. SHOULD be considered the current representation of that resource.
For a GET or HEAD request, this is the same as the default semantics For a GET or HEAD request, this is the same as the default semantics
when no Content-Location is provided by the server. For a state- when no Content-Location is provided by the server. For a state-
changing method like PUT or POST, it implies that the server's changing request like PUT or POST, it implies that the server's
response contains the new representation of that resource, thereby response contains the new representation of that resource, thereby
distinguishing it from representations that might only report about distinguishing it from representations that might only report about
the action (e.g., "It worked!"). This allows authoring applications the action (e.g., "It worked!"). This allows authoring applications
to update their local copies without the need for a subsequent GET to update their local copies without the need for a subsequent GET
request. request.
If Content-Location is included in a response message and its value If Content-Location is included in a response message and its value
differs from the effective request URI, then the origin server is differs from the effective request URI, then the origin server is
informing recipients that this representation has its own, presumably informing recipients that this representation has its own, presumably
more specific, identifier. For a GET or HEAD request, this is an more specific, identifier. For a GET or HEAD request, this is an
indication that the effective request URI identifies a resource that indication that the effective request URI identifies a resource that
is subject to content negotiation and the representation selected for is subject to content negotiation and the representation selected for
this response can also be found at the identified URI. For other this response can also be found at the identified URI. For other
methods, such a Content-Location indicates that this representation methods, such a Content-Location indicates that this representation
contains a report on the action's status and the same report is contains a report on the action's status and the same report is
available (for future access with GET) at the given URI. For available (for future access with GET) at the given URI. For
example, a purchase transaction made via the POST method might example, a purchase transaction made via a POST request might include
include a receipt document as the payload of the 200 response; the a receipt document as the payload of the 200 response; the Content-
Content-Location value provides an identifier for retrieving a copy Location value provides an identifier for retrieving a copy of that
of that same receipt in the future. same receipt in the future.
If Content-Location is included in a request message, then it MAY be If Content-Location is included in a request message, then it MAY be
interpreted by the origin server as an indication of where the user interpreted by the origin server as an indication of where the user
agent originally obtained the content of the enclosed representation agent originally obtained the content of the enclosed representation
(prior to any subsequent modification of the content by that user (prior to any subsequent modification of the content by that user
agent). In other words, the user agent is providing the same agent). In other words, the user agent is providing the same
representation metadata that it received with the original representation metadata that it received with the original
representation. However, such interpretation MUST NOT be used to representation. However, such interpretation MUST NOT be used to
alter the semantics of the method requested by the client. For alter the semantics of the method requested by the client. For
example, if a client makes a PUT request on a negotiated resource and example, if a client makes a PUT request on a negotiated resource and
skipping to change at page 26, line 8 skipping to change at page 25, line 48
transfer-coding is decoded). Note that a MIC is good for detecting transfer-coding is decoded). Note that a MIC is good for detecting
accidental modification of the payload body in transit, but is not accidental modification of the payload body in transit, but is not
proof against malicious attacks. proof against malicious attacks.
Content-MD5 = "Content-MD5" ":" OWS Content-MD5-v Content-MD5 = "Content-MD5" ":" OWS Content-MD5-v
Content-MD5-v = <base64 of 128 bit MD5 digest as per [RFC1864]> Content-MD5-v = <base64 of 128 bit MD5 digest as per [RFC1864]>
The Content-MD5 header field MAY be generated by an origin server or The Content-MD5 header field MAY be generated by an origin server or
client to function as an integrity check of the payload body. Only client to function as an integrity check of the payload body. Only
origin servers or user agents MAY generate the Content-MD5 header origin servers or user agents MAY generate the Content-MD5 header
field; proxies and gateways MUST NOT generate it, as this would field; proxies MUST NOT generate it, as this would defeat its value
defeat its value as an end-to-end integrity check. Any recipient MAY as an end-to-end integrity check. Any recipient MAY check that the
check that the digest value in this header field matches a digest value in this header field matches a corresponding digest
corresponding digest calculated on payload body as received. calculated on payload body as received.
The MD5 digest is computed based on the content of the payload body, The MD5 digest is computed based on the content of the payload body,
including any content-coding, but not including any transfer-coding including any content-coding, but not including any transfer-coding
applied to the message-body because such transfer-codings might be applied to the message-body because such transfer-codings might be
applied or removed anywhere along the request/response chain. If the applied or removed anywhere along the request/response chain. If the
message is received with a transfer-coding, that encoding MUST be message is received with a transfer-coding, that encoding MUST be
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
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 Header Fields 8.1. Privacy Issues Connected to Accept Header Fields
Accept request-headers fields can reveal information about the user Accept headers fields can reveal information about the user to all
to all servers which are accessed. The Accept-Language header field servers which are accessed. The Accept-Language header field in
in particular can reveal information the user would consider to be of particular can reveal information the user would consider to be of a
a private nature, because the understanding of particular languages private nature, because the understanding of particular languages is
is often strongly correlated to the membership of a particular ethnic often strongly correlated to the membership of a particular ethnic
group. User agents which offer the option to configure the contents group. User agents which offer the option to configure the contents
of an Accept-Language header field to be sent in every request are of an Accept-Language header field to be sent in every request are
strongly encouraged to let the configuration process include a strongly encouraged to let the configuration process include a
message which 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 header fields by default, and to omit the sending of Accept-Language header fields by default, and
to ask the user whether or not to start sending Accept-Language to ask the user whether or not to start sending Accept-Language
header fields to a server if it detects, by looking for any Vary header fields to a server if it detects, by looking for any Vary
response-header fields generated by the server, that such sending header fields generated by the server, that such sending could
could improve the quality of service. 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
skipping to change at page 29, line 32 skipping to change at page 29, line 29
[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-12 (work in progress), draft-ietf-httpbis-p1-messaging-13 (work in progress),
October 2010. March 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., 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-12 (work in Semantics", draft-ietf-httpbis-p2-semantics-13 (work in
progress), October 2010. progress), March 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., 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-12 (work in draft-ietf-httpbis-p4-conditional-13 (work in
progress), October 2010. progress), March 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., 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-12 (work in progress), draft-ietf-httpbis-p5-range-13 (work in progress),
October 2010. March 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., 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-12 (work in progress), draft-ietf-httpbis-p6-cache-13 (work in progress),
October 2010. March 2011.
[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 33, line 8 skipping to change at page 32, line 50
This appendix describes specific areas where HTTP differs from MIME. This appendix describes specific areas where HTTP differs from MIME.
Proxies and gateways to strict MIME environments SHOULD be aware of Proxies and gateways to strict MIME environments SHOULD be aware of
these differences and provide the appropriate conversions where these differences and provide the appropriate conversions where
necessary. Proxies and gateways from MIME environments to HTTP also necessary. Proxies and gateways from MIME environments to HTTP also
need to be aware of the differences because some conversions might be need to be aware of the differences because some conversions might be
required. required.
A.1. MIME-Version A.1. MIME-Version
HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages
MAY include a single MIME-Version general-header field to indicate MAY include a single MIME-Version header field to indicate what
what version of the MIME protocol was used to construct the message. version of the MIME protocol was used to construct the message. Use
Use of the MIME-Version header field indicates that the message is in of the MIME-Version header field indicates that the message is in
full compliance with the MIME protocol (as defined in [RFC2045]). full compliance with the MIME protocol (as defined in [RFC2045]).
Proxies/gateways are responsible for ensuring full compliance (where Proxies/gateways are responsible for ensuring full compliance (where
possible) when exporting HTTP messages to strict MIME environments. possible) when exporting HTTP messages to strict MIME environments.
MIME-Version = "MIME-Version" ":" OWS MIME-Version-v MIME-Version = "MIME-Version" ":" OWS MIME-Version-v
MIME-Version-v = 1*DIGIT "." 1*DIGIT MIME-Version-v = 1*DIGIT "." 1*DIGIT
MIME version "1.0" is the default for use in HTTP/1.1. However, MIME version "1.0" is the default for use in HTTP/1.1. However,
HTTP/1.1 message parsing and semantics are defined by this document HTTP/1.1 message parsing and semantics are defined by this document
and not the MIME specification. and not the MIME specification.
skipping to change at page 33, line 39 skipping to change at page 33, line 32
represent line breaks as CRLF and forbids the use of CR or LF outside represent line breaks as CRLF and forbids the use of CR or LF outside
of line break sequences. HTTP allows CRLF, bare CR, and bare LF to of line break sequences. HTTP allows CRLF, bare CR, and bare LF to
indicate a line break within text content when a message is indicate a line break within text content when a message is
transmitted over HTTP. transmitted over HTTP.
Where it is possible, a proxy or gateway from HTTP to a strict MIME Where it is possible, a proxy or gateway from HTTP to a strict MIME
environment SHOULD translate all line breaks within the text media environment SHOULD translate all line breaks within the text media
types described in Section 2.3.1 of this document to the RFC 2049 types described in Section 2.3.1 of this document to the RFC 2049
canonical form of CRLF. Note, however, that this might be canonical form of CRLF. Note, however, that this might be
complicated by the presence of a Content-Encoding and by the fact complicated by the presence of a Content-Encoding and by the fact
that HTTP allows the use of some character sets which do not use that HTTP allows the use of some character encodings which do not use
octets 13 and 10 to represent CR and LF, as is the case for some octets 13 and 10 to represent CR and LF, respectively, as is the case
multi-byte character sets. for some multi-byte character encodings.
Conversion will break any cryptographic checksums applied to the Conversion will break any cryptographic checksums applied to the
original content unless the original content is already in canonical original content unless the original content is already in canonical
form. Therefore, the canonical form is recommended for any content form. Therefore, the canonical form is recommended for any content
that uses such checksums in HTTP. that uses such checksums in HTTP.
A.3. Conversion of Date Formats A.3. Conversion of Date Formats
HTTP/1.1 uses a restricted set of date formats (Section 6.1 of HTTP/1.1 uses a restricted set of date formats (Section 6.1 of
[Part1]) to simplify the process of date comparison. Proxies and [Part1]) to simplify the process of date comparison. Proxies and
skipping to change at page 36, line 6 skipping to change at page 35, line 50
] ) ] )
Accept-v = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [ Accept-v = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
OWS media-range [ accept-params ] ] ) ] OWS media-range [ accept-params ] ] ) ]
Content-Encoding = "Content-Encoding:" OWS Content-Encoding-v Content-Encoding = "Content-Encoding:" OWS Content-Encoding-v
Content-Encoding-v = *( "," OWS ) content-coding *( OWS "," [ OWS Content-Encoding-v = *( "," OWS ) content-coding *( OWS "," [ OWS
content-coding ] ) content-coding ] )
Content-Language = "Content-Language:" OWS Content-Language-v Content-Language = "Content-Language:" OWS Content-Language-v
Content-Language-v = *( "," OWS ) language-tag *( OWS "," [ OWS Content-Language-v = *( "," OWS ) language-tag *( OWS "," [ OWS
language-tag ] ) language-tag ] )
Content-Length = <Content-Length, defined in [Part1], Section 9.2>
Content-Location = "Content-Location:" OWS Content-Location-v Content-Location = "Content-Location:" OWS Content-Location-v
Content-Location-v = absolute-URI / partial-URI Content-Location-v = absolute-URI / partial-URI
Content-MD5 = "Content-MD5:" OWS Content-MD5-v Content-MD5 = "Content-MD5:" OWS Content-MD5-v
Content-MD5-v = <base64 of 128 bit MD5 digest as per [RFC1864]> Content-MD5-v = <base64 of 128 bit MD5 digest as per [RFC1864]>
Content-Range = <Content-Range, defined in [Part5], Section 5.2>
Content-Type = "Content-Type:" OWS Content-Type-v Content-Type = "Content-Type:" OWS Content-Type-v
Content-Type-v = media-type Content-Type-v = media-type
Expires = <Expires, defined in [Part6], Section 3.3>
Last-Modified = <Last-Modified, defined in [Part4], Section 6.6>
MIME-Version = "MIME-Version:" OWS MIME-Version-v MIME-Version = "MIME-Version:" OWS MIME-Version-v
MIME-Version-v = 1*DIGIT "." 1*DIGIT MIME-Version-v = 1*DIGIT "." 1*DIGIT
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
skipping to change at page 37, line 4 skipping to change at page 36, line 41
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>
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
; 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-Type defined but not used ; Content-Type defined but not used
; Expires defined but not used
; Last-Modified defined but not used
; MIME-Version defined but not used ; MIME-Version 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 RFC 2616 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
skipping to change at page 42, line 20 skipping to change at page 42, line 17
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 E.13. Since draft-ietf-httpbis-p3-payload-11
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/123>: "Factor out o <http://tools.ietf.org/wg/httpbis/trac/ticket/123>: "Factor out
Content-Disposition" Content-Disposition"
E.14. Since draft-ietf-httpbis-p3-payload-12
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/224>: "Header
Classification"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle
ABNFs for header fields"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/277>: "potentially
misleading MAY in media-type def"
Index Index
A A
Accept header 17 Accept header field 16
Accept-Charset header 19 Accept-Charset header field 19
Accept-Encoding header 20 Accept-Encoding header field 19
Accept-Language header 21 Accept-Language header field 21
C C
Coding Format Coding Format
compress 8 compress 7
deflate 8 deflate 8
gzip 8 gzip 8
identity 8 identity 8
compress (Coding Format) 8 compress (Coding Format) 7
content negotiation 5 content negotiation 5
Content-Encoding header 22 Content-Encoding header field 22
Content-Language header 23 Content-Language header field 23
Content-Location header 24 Content-Location header field 24
Content-MD5 header 25 Content-MD5 header field 25
Content-Type header 27 Content-Type header field 26
D D
deflate (Coding Format) 8 deflate (Coding Format) 8
G G
Grammar Grammar
Accept 17 Accept 17
Accept-Charset 19 Accept-Charset 19
Accept-Charset-v 19 Accept-Charset-v 19
Accept-Encoding 20 Accept-Encoding 20
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 6
codings 20 codings 20
content-coding 8 content-coding 7
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 26
Content-Type-v 27 Content-Type-v 26
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 Header Fields
Accept 17 Accept 16
Accept-Charset 19 Accept-Charset 19
Accept-Encoding 20 Accept-Encoding 19
Accept-Language 21 Accept-Language 21
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 26
MIME-Version 33 MIME-Version 32
I I
identity (Coding Format) 8 identity (Coding Format) 8
M M
MIME-Version header 33 MIME-Version header field 32
P P
payload 12 payload 11
R R
representation 12 representation 12
Authors' Addresses Authors' Addresses
Roy T. Fielding (editor) Roy T. Fielding (editor)
Day Software Adobe Systems Incorporated
23 Corporate Plaza DR, Suite 280 345 Park Ave
Newport Beach, CA 92660 San Jose, CA 95110
USA USA
Phone: +1-949-706-5300
Fax: +1-949-706-5305
EMail: fielding@gbiv.com EMail: fielding@gbiv.com
URI: http://roy.gbiv.com/ URI: http://roy.gbiv.com/
Jim Gettys Jim Gettys
Alcatel-Lucent Bell Labs Alcatel-Lucent Bell Labs
21 Oak Knoll Road 21 Oak Knoll Road
Carlisle, MA 01741 Carlisle, MA 01741
USA USA
EMail: jg@freedesktop.org EMail: jg@freedesktop.org
skipping to change at page 44, line 41 skipping to change at page 45, line 4
URI: http://gettys.wordpress.com/ URI: http://gettys.wordpress.com/
Jeffrey C. Mogul Jeffrey C. Mogul
Hewlett-Packard Company Hewlett-Packard Company
HP Labs, Large Scale Systems Group HP Labs, Large Scale Systems Group
1501 Page Mill Road, MS 1177 1501 Page Mill Road, MS 1177
Palo Alto, CA 94304 Palo Alto, CA 94304
USA USA
EMail: JeffMogul@acm.org EMail: JeffMogul@acm.org
Henrik Frystyk Nielsen Henrik Frystyk Nielsen
Microsoft Corporation Microsoft Corporation
1 Microsoft Way 1 Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
USA USA
EMail: henrikn@microsoft.com EMail: henrikn@microsoft.com
Larry Masinter Larry Masinter
Adobe Systems, Incorporated Adobe Systems Incorporated
345 Park Ave 345 Park Ave
San Jose, CA 95110 San Jose, CA 95110
USA USA
EMail: LMM@acm.org EMail: LMM@acm.org
URI: http://larry.masinter.net/ URI: http://larry.masinter.net/
Paul J. Leach Paul J. Leach
Microsoft Corporation Microsoft Corporation
1 Microsoft Way 1 Microsoft Way
 End of changes. 75 change blocks. 
178 lines changed or deleted 164 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/