draft-ietf-httpbis-p3-payload-13.txt   draft-ietf-httpbis-p3-payload-14.txt 
HTTPbis Working Group R. Fielding, Ed. HTTPbis Working Group R. Fielding, Ed.
Internet-Draft Adobe Internet-Draft Adobe
Obsoletes: 2616 (if approved) J. Gettys Obsoletes: 2616 (if approved) J. Gettys
Intended status: Standards Track Alcatel-Lucent Intended status: Standards Track Alcatel-Lucent
Expires: September 15, 2011 J. Mogul Expires: October 20, 2011 J. Mogul
HP HP
H. Frystyk H. Frystyk
Microsoft Microsoft
L. Masinter L. Masinter
Adobe Adobe
P. Leach P. Leach
Microsoft Microsoft
T. Berners-Lee T. Berners-Lee
W3C/MIT W3C/MIT
Y. Lafon, Ed. Y. Lafon, Ed.
W3C W3C
J. Reschke, Ed. J. Reschke, Ed.
greenbytes greenbytes
March 14, 2011 April 18, 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-13 draft-ietf-httpbis-p3-payload-14
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), which is archived at
at <http://tools.ietf.org/wg/httpbis/trac/report/3> and related <http://lists.w3.org/Archives/Public/ietf-http-wg/>.
The current issues list is 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.14. The changes in this draft are summarized in Appendix E.15.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
skipping to change at page 2, line 15 skipping to change at page 2, line 17
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 September 15, 2011. This Internet-Draft will expire on October 20, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 4 skipping to change at page 3, line 7
Table of Contents Table of Contents
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 Encodings (charset) . . . . . . . . . . . . . . 6 2.1. Character Encodings (charset) . . . . . . . . . . . . . . 6
2.1.1. Missing Charset . . . . . . . . . . . . . . . . . . . 7
2.2. Content Codings . . . . . . . . . . . . . . . . . . . . . 7 2.2. Content Codings . . . . . . . . . . . . . . . . . . . . . 7
2.2.1. Content Coding Registry . . . . . . . . . . . . . . . 8 2.2.1. Content Coding Registry . . . . . . . . . . . . . . . 8
2.3. Media Types . . . . . . . . . . . . . . . . . . . . . . . 8 2.3. Media Types . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.1. Canonicalization and Text Defaults . . . . . . . . . . 9 2.3.1. Canonicalization and Text Defaults . . . . . . . . . . 9
2.3.2. Multipart Types . . . . . . . . . . . . . . . . . . . 10 2.3.2. Multipart Types . . . . . . . . . . . . . . . . . . . 9
2.4. Language Tags . . . . . . . . . . . . . . . . . . . . . . 10 2.4. Language Tags . . . . . . . . . . . . . . . . . . . . . . 10
3. Payload . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3. Payload . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Payload Header Fields . . . . . . . . . . . . . . . . . . 11 3.1. Payload Header Fields . . . . . . . . . . . . . . . . . . 11
3.2. Payload Body . . . . . . . . . . . . . . . . . . . . . . . 12 3.2. Payload Body . . . . . . . . . . . . . . . . . . . . . . . 11
4. Representation . . . . . . . . . . . . . . . . . . . . . . . . 12 4. Representation . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Representation Header Fields . . . . . . . . . . . . . . . 12 4.1. Representation Header Fields . . . . . . . . . . . . . . . 12
4.2. Representation Data . . . . . . . . . . . . . . . . . . . 13 4.2. Representation Data . . . . . . . . . . . . . . . . . . . 12
5. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 14 5. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 13
5.1. Server-driven Negotiation . . . . . . . . . . . . . . . . 15 5.1. Server-driven Negotiation . . . . . . . . . . . . . . . . 14
5.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . . 16 5.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . . 15
6. Header Field Definitions . . . . . . . . . . . . . . . . . . . 16 6. Header Field Definitions . . . . . . . . . . . . . . . . . . . 16
6.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . . 19 6.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . . 18
6.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 19 6.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 19
6.4. Accept-Language . . . . . . . . . . . . . . . . . . . . . 21 6.4. Accept-Language . . . . . . . . . . . . . . . . . . . . . 20
6.5. Content-Encoding . . . . . . . . . . . . . . . . . . . . . 22 6.5. Content-Encoding . . . . . . . . . . . . . . . . . . . . . 21
6.6. Content-Language . . . . . . . . . . . . . . . . . . . . . 23 6.6. Content-Language . . . . . . . . . . . . . . . . . . . . . 22
6.7. Content-Location . . . . . . . . . . . . . . . . . . . . . 24 6.7. Content-Location . . . . . . . . . . . . . . . . . . . . . 23
6.8. Content-MD5 . . . . . . . . . . . . . . . . . . . . . . . 25 6.8. Content-Type . . . . . . . . . . . . . . . . . . . . . . . 24
6.9. Content-Type . . . . . . . . . . . . . . . . . . . . . . . 26 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 7.1. Header Field Registration . . . . . . . . . . . . . . . . 24
7.1. Header Field Registration . . . . . . . . . . . . . . . . 27 7.2. Content Coding Registry . . . . . . . . . . . . . . . . . 25
7.2. Content Coding Registry . . . . . . . . . . . . . . . . . 27 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25
8. Security Considerations . . . . . . . . . . . . . . . . . . . 28 8.1. Privacy Issues Connected to Accept Header Fields . . . . . 26
8.1. Privacy Issues Connected to Accept Header Fields . . . . . 28 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 10.1. Normative References . . . . . . . . . . . . . . . . . . . 26
10.1. Normative References . . . . . . . . . . . . . . . . . . . 29 10.2. Informative References . . . . . . . . . . . . . . . . . . 29
10.2. Informative References . . . . . . . . . . . . . . . . . . 31 Appendix A. Differences between HTTP and MIME . . . . . . . . . . 31
Appendix A. Differences between HTTP and MIME . . . . . . . . . . 32 A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 31
A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 32 A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 32
A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 33 A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 32
A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 33 A.4. Introduction of Content-Encoding . . . . . . . . . . . . . 32
A.4. Introduction of Content-Encoding . . . . . . . . . . . . . 34 A.5. No Content-Transfer-Encoding . . . . . . . . . . . . . . . 33
A.5. No Content-Transfer-Encoding . . . . . . . . . . . . . . . 34 A.6. Introduction of Transfer-Encoding . . . . . . . . . . . . 33
A.6. Introduction of Transfer-Encoding . . . . . . . . . . . . 34 A.7. MHTML and Line Length Limitations . . . . . . . . . . . . 33
A.7. MHTML and Line Length Limitations . . . . . . . . . . . . 34 Appendix B. Additional Features . . . . . . . . . . . . . . . . . 33
Appendix B. Additional Features . . . . . . . . . . . . . . . . . 34 Appendix C. Changes from RFC 2616 . . . . . . . . . . . . . . . . 34
Appendix C. Changes from RFC 2616 . . . . . . . . . . . . . . . . 35 Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 34
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) . . . . . . . . . . . . . . . . . . . . 36
E.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 37 E.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 36
E.2. Since draft-ietf-httpbis-p3-payload-00 . . . . . . . . . . 37 E.2. Since draft-ietf-httpbis-p3-payload-00 . . . . . . . . . . 36
E.3. Since draft-ietf-httpbis-p3-payload-01 . . . . . . . . . . 38 E.3. Since draft-ietf-httpbis-p3-payload-01 . . . . . . . . . . 37
E.4. Since draft-ietf-httpbis-p3-payload-02 . . . . . . . . . . 38 E.4. Since draft-ietf-httpbis-p3-payload-02 . . . . . . . . . . 37
E.5. Since draft-ietf-httpbis-p3-payload-03 . . . . . . . . . . 38 E.5. Since draft-ietf-httpbis-p3-payload-03 . . . . . . . . . . 37
E.6. Since draft-ietf-httpbis-p3-payload-04 . . . . . . . . . . 39 E.6. Since draft-ietf-httpbis-p3-payload-04 . . . . . . . . . . 38
E.7. Since draft-ietf-httpbis-p3-payload-05 . . . . . . . . . . 39 E.7. Since draft-ietf-httpbis-p3-payload-05 . . . . . . . . . . 38
E.8. Since draft-ietf-httpbis-p3-payload-06 . . . . . . . . . . 39 E.8. Since draft-ietf-httpbis-p3-payload-06 . . . . . . . . . . 38
E.9. Since draft-ietf-httpbis-p3-payload-07 . . . . . . . . . . 40 E.9. Since draft-ietf-httpbis-p3-payload-07 . . . . . . . . . . 39
E.10. Since draft-ietf-httpbis-p3-payload-08 . . . . . . . . . . 40 E.10. Since draft-ietf-httpbis-p3-payload-08 . . . . . . . . . . 39
E.11. Since draft-ietf-httpbis-p3-payload-09 . . . . . . . . . . 41 E.11. Since draft-ietf-httpbis-p3-payload-09 . . . . . . . . . . 39
E.12. Since draft-ietf-httpbis-p3-payload-10 . . . . . . . . . . 41 E.12. Since draft-ietf-httpbis-p3-payload-10 . . . . . . . . . . 40
E.13. Since draft-ietf-httpbis-p3-payload-11 . . . . . . . . . . 42 E.13. Since draft-ietf-httpbis-p3-payload-11 . . . . . . . . . . 41
E.14. Since draft-ietf-httpbis-p3-payload-12 . . . . . . . . . . 42 E.14. Since draft-ietf-httpbis-p3-payload-12 . . . . . . . . . . 41
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 E.15. Since draft-ietf-httpbis-p3-payload-13 . . . . . . . . . . 41
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
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 7, line 14 skipping to change at page 7, line 14
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].
2.1.1. Missing Charset
Some HTTP/1.0 software has interpreted a Content-Type header field
without charset parameter incorrectly to mean "recipient should
guess". Senders wishing to defeat this behavior MAY include a
charset parameter even when the charset is ISO-8859-1 ([ISO-8859-1])
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
an explicit charset parameter. HTTP/1.1 recipients MUST respect the
charset label provided by the sender; and those user agents that have
a provision to "guess" a charset MUST use the charset from the
content-type field if they support that charset, rather than the
recipient's preference, when initially displaying a document. See
Section 2.3.1.
2.2. Content Codings 2.2. Content Codings
Content coding values indicate an encoding transformation that has Content coding values indicate an encoding transformation that has
been or can be applied to a representation. Content codings are been or can be applied to a representation. Content codings are
primarily used to allow a representation to be compressed or primarily used to allow a representation to be compressed or
otherwise usefully transformed without losing the identity of its otherwise usefully transformed without losing the identity of its
underlying media type and without loss of information. Frequently, underlying media type and without loss of information. Frequently,
the representation is stored in coded form, transmitted directly, and the representation is stored in coded form, transmitted directly, and
only decoded by the recipient. only decoded by the recipient.
skipping to change at page 8, line 49 skipping to change at page 8, line 33
Values to be added to this name space require a specification (see Values to be added to this name space require a specification (see
"Specification Required" in Section 4.1 of [RFC5226]), and MUST "Specification Required" in Section 4.1 of [RFC5226]), and MUST
conform to the purpose of content coding defined in this section. conform to the purpose of content coding defined in this section.
The registry itself is maintained at The registry itself is maintained at
<http://www.iana.org/assignments/http-parameters>. <http://www.iana.org/assignments/http-parameters>.
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.8) 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
The type/subtype MAY be followed by parameters in the form of The type/subtype MAY be followed by parameters in the form of
attribute/value pairs. attribute/value pairs.
parameter = attribute "=" value parameter = attribute "=" value
skipping to change at page 10, line 12 skipping to change at page 9, line 43
multi-byte character encodings, HTTP allows the use of whatever octet multi-byte character encodings, HTTP allows the use of whatever octet
sequences are defined by that character encoding to represent the sequences are defined by that character encoding to represent the
equivalent of CR and LF for line breaks. This flexibility regarding equivalent of CR and LF for line breaks. This flexibility regarding
line breaks applies only to text media in the payload body; a bare CR line breaks applies only to text media in the payload body; a bare CR
or LF MUST NOT be substituted for CRLF within any of the HTTP control or LF MUST NOT be substituted for CRLF within any of the HTTP control
structures (such as header fields and multipart boundaries). structures (such as header fields and multipart boundaries).
If a representation is encoded with a content-coding, the underlying If a representation is encoded with a content-coding, the underlying
data MUST be in a form defined above prior to being encoded. data MUST be in a form defined above prior to being encoded.
The "charset" parameter is used with some media types to define the
character encoding (Section 2.1) of the data. When no explicit
charset parameter is provided by the sender, media subtypes of the
"text" type are defined to have a default charset value of
"ISO-8859-1" when received via HTTP. Data in character encodings
other than "ISO-8859-1" or its subsets MUST be labeled with an
appropriate charset value. See Section 2.1.1 for compatibility
problems.
2.3.2. Multipart Types 2.3.2. Multipart Types
MIME provides for a number of "multipart" types -- encapsulations of MIME provides for a number of "multipart" types -- encapsulations of
one or more representations within a single message-body. All one or more representations within a single message-body. All
multipart types share a common syntax, as defined in Section 5.1.1 of multipart types share a common syntax, as defined in Section 5.1.1 of
[RFC2046], and MUST include a boundary parameter as part of the media [RFC2046], and MUST include a boundary parameter as part of the media
type value. The message body is itself a protocol element and MUST type value. The message body is itself a protocol element and MUST
therefore use only CRLF to represent line breaks between body-parts. therefore use only CRLF to represent line breaks between body-parts.
In general, HTTP treats a multipart message-body no differently than In general, HTTP treats a multipart message-body no differently than
skipping to change at page 11, line 48 skipping to change at page 11, line 22
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:
+-------------------+------------------------+ +-------------------+------------------------+
| Header Field Name | Defined in... | | Header Field Name | Defined in... |
+-------------------+------------------------+ +-------------------+------------------------+
| Content-Length | Section 9.2 of [Part1] | | Content-Length | Section 9.2 of [Part1] |
| Content-MD5 | Section 6.8 |
| Content-Range | Section 5.2 of [Part5] | | 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.
skipping to change at page 13, line 11 skipping to change at page 12, line 23
request URI. request URI.
The following header fields are defined as representation metadata: The following header fields are defined as representation metadata:
+-------------------+------------------------+ +-------------------+------------------------+
| Header Field Name | Defined in... | | Header Field Name | Defined in... |
+-------------------+------------------------+ +-------------------+------------------------+
| Content-Encoding | Section 6.5 | | Content-Encoding | Section 6.5 |
| Content-Language | Section 6.6 | | Content-Language | Section 6.6 |
| Content-Location | Section 6.7 | | Content-Location | Section 6.7 |
| Content-Type | Section 6.9 | | Content-Type | Section 6.8 |
| Expires | Section 3.3 of [Part6] | | Expires | Section 3.3 of [Part6] |
| Last-Modified | Section 6.6 of [Part4] | | Last-Modified | Section 2.1 of [Part4] |
+-------------------+------------------------+ +-------------------+------------------------+
4.2. Representation Data 4.2. Representation Data
The representation body associated with an HTTP message is either The representation body associated with an HTTP message is either
provided as the payload body of the message or referred to by the provided as the payload body of the message or referred to by the
message semantics and the effective request URI. The representation message semantics and the effective request URI. The representation
data is in a format and encoding defined by the representation data is in a format and encoding defined by the representation
metadata header fields. metadata header fields.
skipping to change at page 17, line 7 skipping to change at page 16, line 20
fields related to the payload of messages. fields related to the payload of messages.
6.1. Accept 6.1. Accept
The "Accept" header field can be used by user agents to specify The "Accept" header field can be used by user agents to specify
response media types that are acceptable. Accept header fields can response media types that are acceptable. Accept header fields can
be used to indicate that the request is specifically limited to a be used to indicate that the request is specifically limited to a
small set of desired types, as in the case of a request for an in- small set of desired types, as in the case of a request for an in-
line image. line image.
Accept = "Accept" ":" OWS Accept-v Accept = #( 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 ]
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
skipping to change at page 18, line 19 skipping to change at page 17, line 29
Verbally, this would be interpreted as "text/html and text/x-c are Verbally, this would be interpreted as "text/html and text/x-c are
the preferred media types, but if they do not exist, then send the the preferred media types, but if they do not exist, then send the
text/x-dvi representation, and if that does not exist, send the text/ text/x-dvi representation, and if that does not exist, send the text/
plain representation". plain representation".
Media ranges can be overridden by more specific media ranges or Media ranges can be overridden by more specific media ranges or
specific media types. If more than one media range applies to a specific media types. If more than one media range applies to a
given type, the most specific reference has precedence. For example, given type, the most specific reference has precedence. For example,
Accept: text/*, text/html, text/html;level=1, */* Accept: text/*, text/plain, text/plain;format=flowed, */*
have the following precedence: have the following precedence:
1. text/html;level=1 1. text/plain;format=flowed
2. text/html 2. text/plain
3. text/* 3. text/*
4. */* 4. */*
The media type quality factor associated with a given type is The media type quality factor associated with a given type is
determined by finding the media range with the highest precedence determined by finding the media range with the highest precedence
which matches that type. For example, which matches that type. For example,
Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
skipping to change at page 19, line 16 skipping to change at page 18, line 30
6.2. Accept-Charset 6.2. Accept-Charset
The "Accept-Charset" header field can be used by user agents to The "Accept-Charset" header field can be used by user agents to
indicate what character encodings are acceptable in a response indicate what character encodings are acceptable in a response
payload. This field allows clients capable of understanding more payload. This field allows clients capable of understanding more
comprehensive or special-purpose character encodings to signal that comprehensive or special-purpose character encodings to signal that
capability to a server which is capable of representing documents in capability to a server which is capable of representing documents in
those character encodings. those character encodings.
Accept-Charset = "Accept-Charset" ":" OWS Accept-Charset = 1#( ( charset / "*" )
Accept-Charset-v
Accept-Charset-v = 1#( ( charset / "*" )
[ OWS ";" OWS "q=" qvalue ] ) [ OWS ";" OWS "q=" qvalue ] )
Character encoding values (a.k.a., charsets) are described in Character encoding values (a.k.a., charsets) are described in
Section 2.1. Each charset MAY be given an associated quality value Section 2.1. Each charset MAY be given an associated quality value
which represents the user's preference for that charset. The default which represents the user's preference for that charset. The default
value is q=1. An example 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 encoding (including ISO-8859-1) which is not matches every character encoding which is not mentioned elsewhere in
mentioned elsewhere in the Accept-Charset field. If no "*" is the Accept-Charset field. If no "*" is present in an Accept-Charset
present in an Accept-Charset field, then all character encodings not field, then all character encodings not explicitly mentioned get a
explicitly mentioned get a quality value of 0, except for ISO-8859-1, quality value of 0.
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 encoding is acceptable. If an Accept-Charset header field character encoding is acceptable. If an Accept-Charset header field
is present, and if the server cannot send a response which is is present, and if the server cannot send a response which is
acceptable according to the Accept-Charset header field, then the acceptable according to the Accept-Charset header field, then the
server SHOULD send an error response with the 406 (Not Acceptable) server SHOULD send an error response with the 406 (Not Acceptable)
status code, though the sending of an unacceptable response is also status code, though the sending of an unacceptable response is also
allowed. allowed.
6.3. Accept-Encoding 6.3. Accept-Encoding
The "Accept-Encoding" header field can be used by user agents to The "Accept-Encoding" header field can be used by user agents to
indicate what response content-codings (Section 2.2) are acceptable indicate what response content-codings (Section 2.2) are acceptable
in the response. in the response.
Accept-Encoding = "Accept-Encoding" ":" OWS Accept-Encoding = #( codings [ OWS ";" OWS "q=" qvalue ] )
Accept-Encoding-v codings = ( content-coding / "*" )
Accept-Encoding-v =
#( codings [ OWS ";" OWS "q=" qvalue ] )
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.
Examples of its use are: Examples of its use are:
Accept-Encoding: compress, gzip Accept-Encoding: compress, gzip
Accept-Encoding: Accept-Encoding:
Accept-Encoding: * Accept-Encoding: *
skipping to change at page 21, line 26 skipping to change at page 20, line 30
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" header field can be used by user agents to The "Accept-Language" header field can be used by user agents 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-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
represents an estimate of the user's preference for the languages represents an estimate of the user's preference for the languages
specified by that range. The quality value defaults to "q=1". For specified by that range. The quality value defaults to "q=1". For
example, example,
Accept-Language: da, en-gb;q=0.8, en;q=0.7 Accept-Language: da, en-gb;q=0.8, en;q=0.7
would mean: "I prefer Danish, but will accept British English and would mean: "I prefer Danish, but will accept British English and
skipping to change at page 22, line 32 skipping to change at page 21, line 34
6.5. Content-Encoding 6.5. Content-Encoding
The "Content-Encoding" header field indicates what content-codings The "Content-Encoding" header field indicates what content-codings
have been applied to the representation, and thus what decoding have been applied to the representation, and thus what decoding
mechanisms must be applied in order to obtain the media-type mechanisms must be applied in order to obtain the media-type
referenced by the Content-Type header field. Content-Encoding is referenced by the Content-Type header field. Content-Encoding is
primarily used to allow a representation to be compressed without primarily used to allow a representation to be compressed without
losing the identity of its underlying media type. losing the identity of its underlying media type.
Content-Encoding = "Content-Encoding" ":" OWS Content-Encoding-v Content-Encoding = 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 is only decoded before rendering or analogous usage. However, a
transforming 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"
skipping to change at page 23, line 18 skipping to change at page 22, line 18
applied. Additional information about the encoding parameters MAY be applied. Additional information about the encoding parameters MAY be
provided by other header fields not defined by this specification. provided by other header fields not defined by this specification.
6.6. Content-Language 6.6. Content-Language
The "Content-Language" header field describes the natural language(s) The "Content-Language" header field describes the natural language(s)
of the intended audience for the representation. Note that this of the intended audience for the representation. Note that this
might not be equivalent to all the languages used within the might not be equivalent to all the languages used within the
representation. representation.
Content-Language = "Content-Language" ":" OWS Content-Language-v Content-Language = 1#language-tag
Content-Language-v = 1#language-tag
Language tags are defined in Section 2.4. The primary purpose of Language tags are defined in Section 2.4. The primary purpose of
Content-Language is to allow a user to identify and differentiate Content-Language is to allow a user to identify and differentiate
representations according to the user's own preferred language. representations according to the user's own preferred language.
Thus, if the body content is intended only for a Danish-literate Thus, if the body content is intended only for a Danish-literate
audience, the appropriate field is audience, the appropriate field is
Content-Language: da Content-Language: da
If no Content-Language is specified, the default is that the content If no Content-Language is specified, the default is that the content
skipping to change at page 24, line 13 skipping to change at page 23, line 13
limited to textual documents. limited to textual documents.
6.7. Content-Location 6.7. Content-Location
The "Content-Location" header field supplies a URI that can be used The "Content-Location" header field supplies a URI that can be used
as a specific identifier for the representation in this message. In as a specific identifier for the representation in this message. In
other words, if one were to perform a GET on this URI at the time of other words, if one were to perform a GET on this URI at the time of
this message's generation, then a 200 response would contain the same this message's generation, then a 200 response would contain the same
representation that is enclosed as payload in this message. representation that is enclosed as payload in this message.
Content-Location = "Content-Location" ":" OWS Content-Location = absolute-URI / partial-URI
Content-Location-v
Content-Location-v =
absolute-URI / partial-URI
The Content-Location value is not a replacement for the effective The Content-Location value is not a replacement for the effective
Request URI (Section 4.3 of [Part1]). It is representation metadata. Request URI (Section 4.3 of [Part1]). It is representation metadata.
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
skipping to change at page 25, line 33 skipping to change at page 24, line 30
might be saved for use in other contexts, such as within source links might be saved for use in other contexts, such as within source links
or other metadata. or other metadata.
A cache cannot assume that a representation with a Content-Location A cache cannot assume that a representation with a Content-Location
different from the URI used to retrieve it can be used to respond to different from the URI used to retrieve it can be used to respond to
later requests on that Content-Location URI. later requests on that Content-Location URI.
If the Content-Location value is a partial URI, the partial URI is If the Content-Location value is a partial URI, the partial URI is
interpreted relative to the effective request URI. interpreted relative to the effective request URI.
6.8. Content-MD5 6.8. Content-Type
The "Content-MD5" header field, as defined in [RFC1864], is an MD5
digest of the payload body that provides an end-to-end message
integrity check (MIC) of the payload body (the message-body after any
transfer-coding is decoded). Note that a MIC is good for detecting
accidental modification of the payload body in transit, but is not
proof against malicious attacks.
Content-MD5 = "Content-MD5" ":" OWS Content-MD5-v
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
client to function as an integrity check of the payload body. Only
origin servers or user agents MAY generate the Content-MD5 header
field; proxies MUST NOT generate it, as this would defeat its value
as an end-to-end integrity check. Any recipient MAY check that the
digest value in this header field matches a corresponding digest
calculated on payload body as received.
The MD5 digest is computed based on the content of the payload body,
including any content-coding, but not including any transfer-coding
applied to the message-body because such transfer-codings might be
applied or removed anywhere along the request/response chain. If the
message is received with a transfer-coding, that encoding MUST be
decoded prior to checking the Content-MD5 value against the received
payload.
HTTP extends RFC 1864 to permit the digest to be computed for MIME
composite media-types (e.g., multipart/* and message/rfc822), but
this does not change how the digest is computed as defined in the
preceding paragraph.
There are several consequences of this. The payload for composite
types MAY contain many body-parts, each with its own MIME and HTTP
header fields (including Content-MD5, Content-Transfer-Encoding, and
Content-Encoding header fields). If a body-part has a Content-
Transfer-Encoding or Content-Encoding header field, it is assumed
that the content of the body-part has had the encoding applied, and
the body-part is included in the Content-MD5 digest as is -- i.e.,
after the application. The Transfer-Encoding header field is not
allowed within body-parts.
Conversion of all line breaks to CRLF MUST NOT be done before
computing or checking the digest: the line break convention used in
the text actually transmitted MUST be left unaltered when computing
the digest.
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
in which the application of Content-MD5 to HTTP entity-bodies
differs from its application to MIME entity-bodies. One is that
HTTP, unlike MIME, does not use Content-Transfer-Encoding, and
does use Transfer-Encoding and Content-Encoding. Another is that
HTTP more frequently uses binary content types than MIME, so it is
worth noting that, in such cases, the byte order used to compute
the digest is the transmission byte order defined for the type.
Lastly, HTTP allows transmission of text types with any of several
line break conventions and not just the canonical form using CRLF.
6.9. Content-Type
The "Content-Type" header field indicates the media type of the The "Content-Type" header field indicates the media type of the
representation. In the case of responses to the HEAD method, the representation. In the case of responses to the HEAD method, the
media type is that which would have been sent had the request been a media type is that which would have been sent had the request been a
GET. GET.
Content-Type = "Content-Type" ":" OWS Content-Type-v Content-Type = media-type
Content-Type-v = media-type
Media types are defined in Section 2.3. An example of the field is Media types are defined in Section 2.3. An example of the field is
Content-Type: text/html; charset=ISO-8859-4 Content-Type: text/html; charset=ISO-8859-4
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
skipping to change at page 27, line 30 skipping to change at page 25, line 15
+-------------------+----------+----------+--------------+ +-------------------+----------+----------+--------------+
| 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-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-Type | http | standard | Section 6.8 |
| 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.
skipping to change at page 29, line 20 skipping to change at page 26, line 46
requests. General purpose user agents which provide a high degree of requests. General purpose user agents which provide a high degree of
header configurability SHOULD warn users about the loss of privacy header configurability SHOULD warn users about the loss of privacy
which can be involved. which can be involved.
9. Acknowledgments 9. Acknowledgments
10. References 10. References
10.1. Normative References 10.1. Normative References
[ISO-8859-1] International Organization for Standardization, [Part1] Fielding, R., Ed., Gettys, J.,
"Information technology -- 8-bit single-byte coded Mogul, J., Frystyk, H., Masinter,
graphic character sets -- Part 1: Latin alphabet No. L., Leach, P., Berners-Lee, T.,
1", ISO/IEC 8859-1:1998, 1998. Lafon, Y., Ed., and J. Reschke,
Ed., "HTTP/1.1, part 1: URIs,
Connections, and Message Parsing",
draft-ietf-httpbis-p1-messaging-14
(work in progress), April 2011.
[Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part2] Fielding, R., Ed., Gettys, J.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Mogul, J., Frystyk, H., Masinter,
Ed., and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, L., Leach, P., Berners-Lee, T.,
Connections, and Message Parsing", Lafon, Y., Ed., and J. Reschke,
draft-ietf-httpbis-p1-messaging-13 (work in progress), Ed., "HTTP/1.1, part 2: Message
March 2011. Semantics",
draft-ietf-httpbis-p2-semantics-14
(work in progress), April 2011.
[Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part4] Fielding, R., Ed., Gettys, J.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Mogul, J., Frystyk, H., Masinter,
Ed., and J. Reschke, Ed., "HTTP/1.1, part 2: Message L., Leach, P., Berners-Lee, T.,
Semantics", draft-ietf-httpbis-p2-semantics-13 (work in Lafon, Y., Ed., and J. Reschke,
progress), March 2011. Ed., "HTTP/1.1, part 4:
Conditional Requests", draft-ietf-
httpbis-p4-conditional-14 (work in
progress), April 2011.
[Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part5] Fielding, R., Ed., Gettys, J.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Mogul, J., Frystyk, H., Masinter,
Ed., and J. Reschke, Ed., "HTTP/1.1, part 4: L., Leach, P., Berners-Lee, T.,
Conditional Requests", Lafon, Y., Ed., and J. Reschke,
draft-ietf-httpbis-p4-conditional-13 (work in Ed., "HTTP/1.1, part 5: Range
progress), March 2011. Requests and Partial Responses",
draft-ietf-httpbis-p5-range-14
(work in progress), April 2011.
[Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part6] Fielding, R., Ed., Gettys, J.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Mogul, J., Frystyk, H., Masinter,
Ed., and J. Reschke, Ed., "HTTP/1.1, part 5: Range L., Leach, P., Berners-Lee, T.,
Requests and Partial Responses", Lafon, Y., Ed., Nottingham, M.,
draft-ietf-httpbis-p5-range-13 (work in progress), Ed., and J. Reschke, Ed.,
March 2011. "HTTP/1.1, part 6: Caching",
draft-ietf-httpbis-p6-cache-14
(work in progress), April 2011.
[Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Compressed Data Format
Ed., Nottingham, M., Ed., and J. Reschke, Ed., Specification version 3.3",
"HTTP/1.1, part 6: Caching", RFC 1950, May 1996.
draft-ietf-httpbis-p6-cache-13 (work in progress),
March 2011.
[RFC1864] Myers, J. and M. Rose, "The Content-MD5 Header Field", RFC 1950 is an Informational RFC,
RFC 1864, October 1995. thus it might be less stable than
this specification. On the other
hand, this downward reference was
present since the publication of
RFC 2068 in 1997 ([RFC2068]),
therefore it is unlikely to cause
problems in practice. See also
[BCP97].
[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data [RFC1951] Deutsch, P., "DEFLATE Compressed
Format Specification version 3.3", RFC 1950, May 1996. Data Format Specification version
1.3", RFC 1951, May 1996.
RFC 1950 is an Informational RFC, thus it might be less RFC 1951 is an Informational RFC,
stable than this specification. On the other hand, thus it might be less stable than
this downward reference was present since the this specification. On the other
publication of RFC 2068 in 1997 ([RFC2068]), therefore hand, this downward reference was
it is unlikely to cause problems in practice. See also present since the publication of
[BCP97]. RFC 2068 in 1997 ([RFC2068]),
therefore it is unlikely to cause
problems in practice. See also
[BCP97].
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format [RFC1952] Deutsch, P., Gailly, J-L., Adler,
Specification version 1.3", RFC 1951, May 1996. M., Deutsch, L., and G. Randers-
Pehrson, "GZIP file format
specification version 4.3",
RFC 1952, May 1996.
RFC 1951 is an Informational RFC, thus it might be less RFC 1952 is an Informational RFC,
stable than this specification. On the other hand, thus it might be less stable than
this downward reference was present since the this specification. On the other
publication of RFC 2068 in 1997 ([RFC2068]), therefore hand, this downward reference was
it is unlikely to cause problems in practice. See also present since the publication of
[BCP97]. RFC 2068 in 1997 ([RFC2068]),
therefore it is unlikely to cause
problems in practice. See also
[BCP97].
[RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and [RFC2045] Freed, N. and N. Borenstein,
G. Randers-Pehrson, "GZIP file format specification "Multipurpose Internet Mail
version 4.3", RFC 1952, May 1996. Extensions (MIME) Part One: Format
of Internet Message Bodies",
RFC 2045, November 1996.
RFC 1952 is an Informational RFC, thus it might be less [RFC2046] Freed, N. and N. Borenstein,
stable than this specification. On the other hand, "Multipurpose Internet Mail
this downward reference was present since the Extensions (MIME) Part Two: Media
publication of RFC 2068 in 1997 ([RFC2068]), therefore Types", RFC 2046, November 1996.
it is unlikely to cause problems in practice. See also
[BCP97].
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet [RFC2119] Bradner, S., "Key words for use in
Mail Extensions (MIME) Part One: Format of Internet RFCs to Indicate Requirement
Message Bodies", RFC 2045, November 1996. Levels", BCP 14, RFC 2119,
March 1997.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet [RFC4647] Phillips, A., Ed. and M. Davis,
Mail Extensions (MIME) Part Two: Media Types", Ed., "Matching of Language Tags",
RFC 2046, November 1996. BCP 47, RFC 4647, September 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC5234] Crocker, D., Ed. and P. Overell,
Requirement Levels", BCP 14, RFC 2119, March 1997. "Augmented BNF for Syntax
Specifications: ABNF", STD 68,
RFC 5234, January 2008.
[RFC4647] Phillips, A., Ed. and M. Davis, Ed., "Matching of [RFC5646] Phillips, A., Ed. and M. Davis,
Language Tags", BCP 47, RFC 4647, September 2006. Ed., "Tags for Identifying
Languages", BCP 47, RFC 5646,
September 2009.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for 10.2. Informative References
Syntax Specifications: ABNF", STD 68, RFC 5234,
January 2008.
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for [BCP97] Klensin, J. and S. Hartman,
Identifying Languages", BCP 47, RFC 5646, "Handling Normative References to
September 2009. Standards-Track Documents",
BCP 97, RFC 4897, June 2007.
10.2. Informative References [RFC1945] Berners-Lee, T., Fielding, R., and
H. Nielsen, "Hypertext Transfer
Protocol -- HTTP/1.0", RFC 1945,
May 1996.
[BCP97] Klensin, J. and S. Hartman, "Handling Normative [RFC2049] Freed, N. and N. Borenstein,
References to Standards-Track Documents", BCP 97, "Multipurpose Internet Mail
RFC 4897, June 2007. Extensions (MIME) Part Five:
Conformance Criteria and
Examples", RFC 2049,
November 1996.
[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, [RFC2068] Fielding, R., Gettys, J., Mogul,
"Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, J., Nielsen, H., and T. Berners-
May 1996. Lee, "Hypertext Transfer Protocol
-- HTTP/1.1", RFC 2068,
January 1997.
[RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet [RFC2076] Palme, J., "Common Internet
Mail Extensions (MIME) Part Five: Conformance Criteria Message Headers", RFC 2076,
and Examples", RFC 2049, November 1996. February 1997.
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and [RFC2277] Alvestrand, H., "IETF Policy on
T. Berners-Lee, "Hypertext Transfer Protocol -- Character Sets and Languages",
HTTP/1.1", RFC 2068, January 1997. BCP 18, RFC 2277, January 1998.
[RFC2076] Palme, J., "Common Internet Message Headers", RFC 2076, [RFC2295] Holtman, K. and A. Mutz,
February 1997. "Transparent Content Negotiation
in HTTP", RFC 2295, March 1998.
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and [RFC2388] Masinter, L., "Returning Values
Languages", BCP 18, RFC 2277, January 1998. from Forms: multipart/form-data",
RFC 2388, August 1998.
[RFC2295] Holtman, K. and A. Mutz, "Transparent Content [RFC2557] Palme, F., Hopmann, A., Shelness,
Negotiation in HTTP", RFC 2295, March 1998. N., and E. Stefferud, "MIME
Encapsulation of Aggregate
Documents, such as HTML (MHTML)",
RFC 2557, March 1999.
[RFC2388] Masinter, L., "Returning Values from Forms: multipart/ [RFC2616] Fielding, R., Gettys, J., Mogul,
form-data", RFC 2388, August 1998. J., Frystyk, H., Masinter, L.,
Leach, P., and T. Berners-Lee,
"Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
[RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud, [RFC3629] Yergeau, F., "UTF-8, a
"MIME Encapsulation of Aggregate Documents, such as transformation format of ISO
HTML (MHTML)", RFC 2557, March 1999. 10646", STD 63, RFC 3629,
November 2003.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC3864] Klyne, G., Nottingham, M., and J.
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Mogul, "Registration Procedures
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. for Message Header Fields",
BCP 90, RFC 3864, September 2004.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC4288] Freed, N. and J. Klensin, "Media
10646", STD 63, RFC 3629, November 2003. Type Specifications and
Registration Procedures", BCP 13,
RFC 4288, December 2005.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration [RFC5226] Narten, T. and H. Alvestrand,
Procedures for Message Header Fields", BCP 90, "Guidelines for Writing an IANA
RFC 3864, September 2004. Considerations Section in RFCs",
BCP 26, RFC 5226, May 2008.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications [RFC5322] Resnick, P., "Internet Message
and Registration Procedures", BCP 13, RFC 4288, Format", RFC 5322, October 2008.
December 2005.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing [RFC6151] Turner, S. and L. Chen, "Updated
an IANA Considerations Section in RFCs", BCP 26, Security Considerations for the
RFC 5226, May 2008. MD5 Message-Digest and the HMAC-
MD5 Algorithms", RFC 6151,
March 2011.
[RFC5322] Resnick, P., "Internet Message Format", RFC 5322, [draft-ietf-httpbis-content-disp] Reschke, J., "Use of the Content-
October 2008. Disposition Header Field in the
Hypertext Transfer Protocol
(HTTP)",
draft-ietf-httpbis-content-disp-09
(work in progress), March 2011.
Appendix A. Differences between HTTP and MIME Appendix A. Differences between HTTP and MIME
HTTP/1.1 uses many of the constructs defined for Internet Mail HTTP/1.1 uses many of the constructs defined for Internet Mail
([RFC5322]) and the Multipurpose Internet Mail Extensions (MIME ([RFC5322]) and the Multipurpose Internet Mail Extensions (MIME
[RFC2045]) to allow a message-body to be transmitted in an open [RFC2045]) to allow a message-body to be transmitted in an open
variety of representations and with extensible mechanisms. However, variety of representations and with extensible mechanisms. However,
RFC 2045 discusses mail, and HTTP has a few features that are RFC 2045 discusses mail, and HTTP has a few features that are
different from those described in MIME. These differences were different from those described in MIME. These differences were
carefully chosen to optimize performance over binary connections, to carefully chosen to optimize performance over binary connections, to
skipping to change at page 33, line 8 skipping to change at page 31, line 44
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 header field to indicate what MAY include a single MIME-Version header field to indicate what
version of the MIME protocol was used to construct the message. Use version of the MIME protocol was used to construct the message. 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 = 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.
A.2. Conversion to Canonical Form A.2. Conversion to Canonical Form
MIME requires that an Internet mail body-part be converted to MIME requires that an Internet mail body-part be converted to
canonical form prior to being transferred, as described in Section 4 canonical form prior to being transferred, as described in Section 4
of [RFC2049]. Section 2.3.1 of this document describes the forms of [RFC2049]. Section 2.3.1 of this document describes the forms
skipping to change at page 35, line 12 skipping to change at page 33, line 49
[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 header fields, such as Content-Disposition and A number of other header fields, such as Content-Disposition and
Title, from SMTP and MIME are also often implemented (see [RFC2076]). Title, from SMTP and MIME are also often implemented (see
[draft-ietf-httpbis-content-disp] and [RFC2076]).
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 the default character encoding for text media types; the
default now is whatever the media type definition says.
(Section 2.3.1)
Change ABNF productions for header fields to only define the field
value. (Section 6)
Remove definition of Content-MD5 header field because it was
inconsistently implemented with respect to partial responses, and
also because of known deficiencies in the hash algorithm itself (see
[RFC6151] for details). (Section 6)
Remove ISO-8859-1 special-casing in Accept-Charset. (Section 6.2)
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 header fields, and also the emitting bogus Content-Location header fields, and also the
potentially undesirable effect of potentially breaking relative links potentially undesirable effect of potentially breaking relative links
in content-negotiated resources. (Section 6.7) in content-negotiated resources. (Section 6.7)
Remove discussion of Content-Disposition header field, it is now
defined by [draft-ietf-httpbis-content-disp]. (Appendix B)
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 = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
Accept-Charset = "Accept-Charset:" OWS Accept-Charset-v OWS media-range [ accept-params ] ] ) ]
Accept-Charset-v = *( "," OWS ) ( charset / "*" ) [ OWS ";" OWS "q=" Accept-Charset = *( "," OWS ) ( charset / "*" ) [ OWS ";" OWS "q="
qvalue ] *( OWS "," [ OWS ( charset / "*" ) [ OWS ";" OWS "q=" qvalue ] *( OWS "," [ OWS ( charset / "*" ) [ OWS ";" OWS "q="
qvalue ] ] ) qvalue ] ] )
Accept-Encoding = "Accept-Encoding:" OWS Accept-Encoding-v Accept-Encoding = [ ( "," / ( codings [ OWS ";" OWS "q=" qvalue ] ) )
Accept-Encoding-v = [ ( "," / ( codings [ OWS ";" OWS "q=" qvalue ] ) *( OWS "," [ OWS codings [ OWS ";" OWS "q=" qvalue ] ] ) ]
) *( OWS "," [ OWS codings [ OWS ";" OWS "q=" qvalue ] ] ) ] Accept-Language = *( "," OWS ) language-range [ OWS ";" OWS "q="
Accept-Language = "Accept-Language:" OWS Accept-Language-v
Accept-Language-v = *( "," OWS ) language-range [ OWS ";" OWS "q="
qvalue ] *( OWS "," [ OWS language-range [ OWS ";" OWS "q=" qvalue ] qvalue ] *( OWS "," [ OWS language-range [ OWS ";" OWS "q=" qvalue ]
] ) ] )
Accept-v = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
OWS media-range [ accept-params ] ] ) ]
Content-Encoding = "Content-Encoding:" OWS Content-Encoding-v Content-Encoding = *( "," 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 = *( "," OWS ) language-tag *( OWS "," [ OWS
Content-Language-v = *( "," OWS ) language-tag *( OWS "," [ OWS
language-tag ] ) language-tag ] )
Content-Location = "Content-Location:" OWS Content-Location-v Content-Location = absolute-URI / partial-URI
Content-Location-v = absolute-URI / partial-URI Content-Type = media-type
Content-MD5 = "Content-MD5:" OWS Content-MD5-v
Content-MD5-v = <base64 of 128 bit MD5 digest as per [RFC1864]>
Content-Type = "Content-Type:" OWS Content-Type-v
Content-Type-v = media-type
MIME-Version = "MIME-Version:" OWS MIME-Version-v MIME-Version = 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
charset = token charset = token
codings = ( content-coding / "*" ) codings = ( content-coding / "*" )
skipping to change at page 37, line 4 skipping to change at page 35, line 39
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-Location defined but not used ; Content-Location defined but not used
; Content-MD5 defined but not used
; Content-Type defined but not used ; Content-Type 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 30 skipping to change at page 41, line 25
o <http://tools.ietf.org/wg/httpbis/trac/ticket/224>: "Header o <http://tools.ietf.org/wg/httpbis/trac/ticket/224>: "Header
Classification" Classification"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle
ABNFs for header fields" ABNFs for header fields"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/277>: "potentially o <http://tools.ietf.org/wg/httpbis/trac/ticket/277>: "potentially
misleading MAY in media-type def" misleading MAY in media-type def"
E.15. Since draft-ietf-httpbis-p3-payload-13
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/20>: "Default
charsets for text media types"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/178>: "Content-MD5
and partial responses"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle
ABNFs for header fields"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/281>: "confusing
undefined parameter in media range example"
Index Index
A A
Accept header field 16 Accept header field 16
Accept-Charset header field 19 Accept-Charset header field 18
Accept-Encoding header field 19 Accept-Encoding header field 19
Accept-Language header field 21 Accept-Language header field 20
C C
Coding Format Coding Format
compress 7 compress 7
deflate 8 deflate 7
gzip 8 gzip 7
identity 8 identity 7
compress (Coding Format) 7 compress (Coding Format) 7
content negotiation 5 content negotiation 5
Content-Encoding header field 22 Content-Encoding header field 21
Content-Language header field 23 Content-Language header field 22
Content-Location header field 24 Content-Location header field 23
Content-MD5 header field 25 Content-Type header field 24
Content-Type header field 26
D D
deflate (Coding Format) 8 deflate (Coding Format) 7
G G
Grammar Grammar
Accept 17 Accept 16
Accept-Charset 19 Accept-Charset 18
Accept-Charset-v 19 Accept-Encoding 19
Accept-Encoding 20 accept-ext 16
Accept-Encoding-v 20 Accept-Language 20
accept-ext 17 accept-params 16
Accept-Language 21 attribute 8
Accept-Language-v 21
accept-params 17
Accept-v 17
attribute 9
charset 6 charset 6
codings 20 codings 19
content-coding 7 content-coding 7
Content-Encoding 22 Content-Encoding 21
Content-Encoding-v 22 Content-Language 22
Content-Language 23 Content-Location 23
Content-Language-v 23 Content-Type 24
Content-Location 24 language-range 20
Content-Location-v 24 language-tag 10
Content-MD5 25 media-range 16
Content-MD5-v 25 media-type 8
Content-Type 26 MIME-Version 31
Content-Type-v 26 parameter 8
language-range 21 subtype 8
language-tag 11 type 8
media-range 17 value 8
media-type 9 gzip (Coding Format) 7
MIME-Version 33
MIME-Version-v 33
parameter 9
subtype 9
type 9
value 9
gzip (Coding Format) 8
H H
Header Fields Header Fields
Accept 16 Accept 16
Accept-Charset 19 Accept-Charset 18
Accept-Encoding 19 Accept-Encoding 19
Accept-Language 21 Accept-Language 20
Content-Encoding 22 Content-Encoding 21
Content-Language 23 Content-Language 22
Content-Location 24 Content-Location 23
Content-MD5 25 Content-Type 24
Content-Type 26 MIME-Version 31
MIME-Version 32
I I
identity (Coding Format) 8 identity (Coding Format) 7
M M
MIME-Version header field 32 MIME-Version header field 31
P P
payload 11 payload 10
R R
representation 12 representation 11
Authors' Addresses Authors' Addresses
Roy T. Fielding (editor) Roy T. Fielding (editor)
Adobe Systems Incorporated Adobe Systems Incorporated
345 Park Ave 345 Park Ave
San Jose, CA 95110 San Jose, CA 95110
USA USA
EMail: fielding@gbiv.com EMail: fielding@gbiv.com
 End of changes. 100 change blocks. 
384 lines changed or deleted 348 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/