draft-ietf-httpbis-p3-payload-16.txt   draft-ietf-httpbis-p3-payload-17.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: February 25, 2012 J. Mogul Expires: May 3, 2012 J. Mogul
HP HP
H. Frystyk H. Frystyk
Microsoft Microsoft
L. Masinter L. Masinter
Adobe Adobe
P. Leach P. Leach
Microsoft Microsoft
T. Berners-Lee T. Berners-Lee
W3C/MIT W3C/MIT
Y. Lafon, Ed. Y. Lafon, Ed.
W3C W3C
J. Reschke, Ed. J. Reschke, Ed.
greenbytes greenbytes
August 24, 2011 October 31, 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-16 draft-ietf-httpbis-p3-payload-17
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is an application-level The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypertext information protocol for distributed, collaborative, hypertext information
systems. HTTP has been in use by the World Wide Web global systems. HTTP has been in use by the World Wide Web global
information initiative since 1990. This document is Part 3 of the information initiative since 1990. This document is Part 3 of the
seven-part specification that defines the protocol referred to as seven-part specification that defines the protocol referred to as
"HTTP/1.1" and, taken together, obsoletes RFC 2616. "HTTP/1.1" and, taken together, obsoletes RFC 2616.
skipping to change at page 1, line 49 skipping to change at page 1, line 49
Discussion of this draft should take place on the HTTPBIS working Discussion of this draft should take place on the HTTPBIS working
group mailing list (ietf-http-wg@w3.org), which is archived at group mailing list (ietf-http-wg@w3.org), which is archived at
<http://lists.w3.org/Archives/Public/ietf-http-wg/>. <http://lists.w3.org/Archives/Public/ietf-http-wg/>.
The current issues list is at The current issues list is at
<http://tools.ietf.org/wg/httpbis/trac/report/3> and related <http://tools.ietf.org/wg/httpbis/trac/report/3> and related
documents (including fancy diffs) can be found at documents (including fancy diffs) can be found at
<http://tools.ietf.org/wg/httpbis/>. <http://tools.ietf.org/wg/httpbis/>.
The changes in this draft are summarized in Appendix E.17. The changes in this draft are summarized in Appendix E.18.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 25, 2012. This Internet-Draft will expire on May 3, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 4 skipping to change at page 3, line 4
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
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. Conformance and Error Handling . . . . . . . . . . . . . . 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.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 . . . . . . . . . . . . . . . . . . . 9 2.3.2. Multipart Types . . . . . . . . . . . . . . . . . . . 9
2.4. Language Tags . . . . . . . . . . . . . . . . . . . . . . 10 2.4. Language Tags . . . . . . . . . . . . . . . . . . . . . . 10
3. Payload . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3. Payload . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Payload Header Fields . . . . . . . . . . . . . . . . . . 11 3.1. Payload Header Fields . . . . . . . . . . . . . . . . . . 11
3.2. Payload Body . . . . . . . . . . . . . . . . . . . . . . . 11 3.2. Payload Body . . . . . . . . . . . . . . . . . . . . . . . 11
4. Representation . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Representation . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Representation Header Fields . . . . . . . . . . . . . . . 12 4.1. Representation Header Fields . . . . . . . . . . . . . . . 12
4.2. Representation Data . . . . . . . . . . . . . . . . . . . 12 4.2. Representation Data . . . . . . . . . . . . . . . . . . . 12
5. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 13 5. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 13
5.1. Server-driven Negotiation . . . . . . . . . . . . . . . . 14 5.1. Server-driven Negotiation . . . . . . . . . . . . . . . . 14
5.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . . . . . . . 18 6.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . . 18
6.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 19 6.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 19
6.4. Accept-Language . . . . . . . . . . . . . . . . . . . . . 20 6.4. Accept-Language . . . . . . . . . . . . . . . . . . . . . 20
6.5. Content-Encoding . . . . . . . . . . . . . . . . . . . . . 21 6.5. Content-Encoding . . . . . . . . . . . . . . . . . . . . . 21
6.6. Content-Language . . . . . . . . . . . . . . . . . . . . . 22 6.6. Content-Language . . . . . . . . . . . . . . . . . . . . . 22
6.7. Content-Location . . . . . . . . . . . . . . . . . . . . . 23 6.7. Content-Location . . . . . . . . . . . . . . . . . . . . . 23
6.8. Content-Type . . . . . . . . . . . . . . . . . . . . . . . 24 6.8. Content-Type . . . . . . . . . . . . . . . . . . . . . . . 25
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
7.1. Header Field Registration . . . . . . . . . . . . . . . . 25 7.1. Header Field Registration . . . . . . . . . . . . . . . . 25
7.2. Content Coding Registry . . . . . . . . . . . . . . . . . 25 7.2. Content Coding Registry . . . . . . . . . . . . . . . . . 25
8. Security Considerations . . . . . . . . . . . . . . . . . . . 26 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26
8.1. Privacy Issues Connected to Accept Header Fields . . . . . 26 8.1. Privacy Issues Connected to Accept Header Fields . . . . . 26
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
10.1. Normative References . . . . . . . . . . . . . . . . . . . 27 10.1. Normative References . . . . . . . . . . . . . . . . . . . 27
10.2. Informative References . . . . . . . . . . . . . . . . . . 28 10.2. Informative References . . . . . . . . . . . . . . . . . . 29
Appendix A. Differences between HTTP and MIME . . . . . . . . . . 30 Appendix A. Differences between HTTP and MIME . . . . . . . . . . 30
A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 30 A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 30
A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 30 A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 31
A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 31 A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 31
A.4. Introduction of Content-Encoding . . . . . . . . . . . . . 31 A.4. Introduction of Content-Encoding . . . . . . . . . . . . . 31
A.5. No Content-Transfer-Encoding . . . . . . . . . . . . . . . 31 A.5. No Content-Transfer-Encoding . . . . . . . . . . . . . . . 32
A.6. Introduction of Transfer-Encoding . . . . . . . . . . . . 32 A.6. Introduction of Transfer-Encoding . . . . . . . . . . . . 32
A.7. MHTML and Line Length Limitations . . . . . . . . . . . . 32 A.7. MHTML and Line Length Limitations . . . . . . . . . . . . 32
Appendix B. Additional Features . . . . . . . . . . . . . . . . . 32 Appendix B. Additional Features . . . . . . . . . . . . . . . . . 32
Appendix C. Changes from RFC 2616 . . . . . . . . . . . . . . . . 32 Appendix C. Changes from RFC 2616 . . . . . . . . . . . . . . . . 33
Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 33 Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 33
Appendix E. Change Log (to be removed by RFC Editor before Appendix E. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 34 publication) . . . . . . . . . . . . . . . . . . . . 35
E.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 34 E.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 35
E.2. Since draft-ietf-httpbis-p3-payload-00 . . . . . . . . . . 34 E.2. Since draft-ietf-httpbis-p3-payload-00 . . . . . . . . . . 35
E.3. Since draft-ietf-httpbis-p3-payload-01 . . . . . . . . . . 35 E.3. Since draft-ietf-httpbis-p3-payload-01 . . . . . . . . . . 36
E.4. Since draft-ietf-httpbis-p3-payload-02 . . . . . . . . . . 35 E.4. Since draft-ietf-httpbis-p3-payload-02 . . . . . . . . . . 36
E.5. Since draft-ietf-httpbis-p3-payload-03 . . . . . . . . . . 36 E.5. Since draft-ietf-httpbis-p3-payload-03 . . . . . . . . . . 36
E.6. Since draft-ietf-httpbis-p3-payload-04 . . . . . . . . . . 36 E.6. Since draft-ietf-httpbis-p3-payload-04 . . . . . . . . . . 37
E.7. Since draft-ietf-httpbis-p3-payload-05 . . . . . . . . . . 36 E.7. Since draft-ietf-httpbis-p3-payload-05 . . . . . . . . . . 37
E.8. Since draft-ietf-httpbis-p3-payload-06 . . . . . . . . . . 37 E.8. Since draft-ietf-httpbis-p3-payload-06 . . . . . . . . . . 37
E.9. Since draft-ietf-httpbis-p3-payload-07 . . . . . . . . . . 37 E.9. Since draft-ietf-httpbis-p3-payload-07 . . . . . . . . . . 38
E.10. Since draft-ietf-httpbis-p3-payload-08 . . . . . . . . . . 38 E.10. Since draft-ietf-httpbis-p3-payload-08 . . . . . . . . . . 38
E.11. Since draft-ietf-httpbis-p3-payload-09 . . . . . . . . . . 38 E.11. Since draft-ietf-httpbis-p3-payload-09 . . . . . . . . . . 38
E.12. Since draft-ietf-httpbis-p3-payload-10 . . . . . . . . . . 38 E.12. Since draft-ietf-httpbis-p3-payload-10 . . . . . . . . . . 39
E.13. Since draft-ietf-httpbis-p3-payload-11 . . . . . . . . . . 39 E.13. Since draft-ietf-httpbis-p3-payload-11 . . . . . . . . . . 40
E.14. Since draft-ietf-httpbis-p3-payload-12 . . . . . . . . . . 39 E.14. Since draft-ietf-httpbis-p3-payload-12 . . . . . . . . . . 40
E.15. Since draft-ietf-httpbis-p3-payload-13 . . . . . . . . . . 39 E.15. Since draft-ietf-httpbis-p3-payload-13 . . . . . . . . . . 40
E.16. Since draft-ietf-httpbis-p3-payload-14 . . . . . . . . . . 40 E.16. Since draft-ietf-httpbis-p3-payload-14 . . . . . . . . . . 40
E.17. Since draft-ietf-httpbis-p3-payload-15 . . . . . . . . . . 40 E.17. Since draft-ietf-httpbis-p3-payload-15 . . . . . . . . . . 40
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 E.18. Since draft-ietf-httpbis-p3-payload-16 . . . . . . . . . . 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 5, line 35 skipping to change at page 5, line 35
This specification uses a number of terms to refer to the roles This specification uses a number of terms to refer to the roles
played by participants in, and objects of, the HTTP communication. played by participants in, and objects of, the HTTP communication.
content negotiation content negotiation
The mechanism for selecting the appropriate representation when The mechanism for selecting the appropriate representation when
servicing a request. The representation in any response can be servicing a request. The representation in any response can be
negotiated (including error responses). negotiated (including error responses).
1.2. Requirements 1.2. Conformance and Error Handling
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
An implementation is not compliant if it fails to satisfy one or more This document defines conformance criteria for several roles in HTTP
of the "MUST" or "REQUIRED" level requirements for the protocols it communication, including Senders, Recipients, Clients, Servers, User-
implements. An implementation that satisfies all the "MUST" or Agents, Origin Servers, Intermediaries, Proxies and Gateways. See
"REQUIRED" level and all the "SHOULD" level requirements for its Section 2 of [Part1] for definitions of these terms.
protocols is said to be "unconditionally compliant"; one that
satisfies all the "MUST" level requirements but not all the "SHOULD" An implementation is considered conformant if it complies with all of
level requirements for its protocols is said to be "conditionally the requirements associated with its role(s). Note that SHOULD-level
compliant". requirements are relevant here, unless one of the documented
exceptions is applicable.
This document also uses ABNF to define valid protocol elements
(Section 1.3). In addition to the prose requirements placed upon
them, Senders MUST NOT generate protocol elements that are invalid.
Unless noted otherwise, Recipients MAY take steps to recover a usable
protocol element from an invalid construct. However, HTTP does not
define specific error handling mechanisms, except in cases where it
has direct impact on security. This is because different uses of the
protocol require different error handling strategies; for example, a
Web browser may wish to transparently recover from a response where
the Location header field doesn't parse according to the ABNF,
whereby in a systems control protocol using HTTP, this type of error
recovery could lead to dangerous consequences.
1.3. Syntax Notation 1.3. Syntax Notation
This specification uses the ABNF syntax defined in Section 1.2 of This specification uses the ABNF syntax defined in Section 1.2 of
[Part1] (which extends the syntax defined in [RFC5234] with a list [Part1] (which extends the syntax defined in [RFC5234] with a list
rule). Appendix D shows the collected ABNF, with the list rule rule). Appendix D shows the collected ABNF, with the list rule
expanded. expanded.
The following core rules are included by reference, as defined in The following core rules are included by reference, as defined in
[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
(CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit
sequence of data), SP (space), VCHAR (any visible USASCII character), sequence of data), SP (space), and VCHAR (any visible US-ASCII
and WSP (whitespace). character).
1.3.1. Core Rules 1.3.1. Core Rules
The core rules below are defined in [Part1]: The core rules below are defined in [Part1]:
OWS = <OWS, defined in [Part1], Section 1.2.2> OWS = <OWS, defined in [Part1], Section 1.2.2>
token = <token, defined in [Part1], Section 3.2.3> token = <token, defined in [Part1], Section 3.2.3>
word = <word, defined in [Part1], Section 3.2.3> word = <word, defined in [Part1], Section 3.2.3>
1.3.2. ABNF Rules defined in other Parts of the Specification 1.3.2. ABNF Rules defined in other Parts of the Specification
The ABNF rules below are defined in other parts: The ABNF rules below are defined in other parts:
absolute-URI = <absolute-URI, defined in [Part1], Section 2.7> absolute-URI = <absolute-URI, defined in [Part1], Section 2.7>
partial-URI = <partial-URI, defined in [Part1], Section 2.7> partial-URI = <partial-URI, defined in [Part1], Section 2.7>
qvalue = <qvalue, defined in [Part1], Section 6.4> qvalue = <qvalue, defined in [Part1], Section 5.3>
2. Protocol Parameters 2. Protocol Parameters
2.1. Character Encodings (charset) 2.1. Character Encodings (charset)
HTTP uses charset names to indicate the character encoding of a HTTP uses charset names to indicate the character encoding of a
textual representation. textual representation.
A character encoding is identified by a case-insensitive token. 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
skipping to change at page 7, line 35 skipping to change at page 7, line 47
All content-coding values are case-insensitive. HTTP/1.1 uses All content-coding values are case-insensitive. HTTP/1.1 uses
content-coding values in the Accept-Encoding (Section 6.3) and content-coding values in the Accept-Encoding (Section 6.3) and
Content-Encoding (Section 6.5) header fields. Although the value Content-Encoding (Section 6.5) header fields. Although the value
describes the content-coding, what is more important is that it describes the content-coding, what is more important is that it
indicates what decoding mechanism will be required to remove the indicates what decoding mechanism will be required to remove the
encoding. encoding.
compress compress
See Section 6.2.2.1 of [Part1]. See Section 5.1.2.1 of [Part1].
deflate deflate
See Section 6.2.2.2 of [Part1]. See Section 5.1.2.2 of [Part1].
gzip gzip
See Section 6.2.2.3 of [Part1]. See Section 5.1.2.3 of [Part1].
identity
The default (identity) encoding; the use of no transformation
whatsoever. This content-coding is used only in the Accept-
Encoding header field, and SHOULD NOT be used in the Content-
Encoding header field.
2.2.1. Content Coding Registry 2.2.1. Content Coding Registry
The HTTP Content Coding Registry defines the name space for the The HTTP Content Coding Registry defines the name space for the
content coding names. content coding names.
Registrations MUST include the following fields: Registrations MUST include the following fields:
o Name o Name
o Description o Description
o Pointer to specification text o Pointer to specification text
Names of content codings MUST NOT overlap with names of transfer Names of content codings MUST NOT overlap with names of transfer
codings (Section 6.2 of [Part1]), unless the encoding transformation codings (Section 5.1 of [Part1]), unless the encoding transformation
is identical (as it is the case for the compression codings defined is identical (as it is the case for the compression codings defined
in Section 6.2.2 of [Part1]). in Section 5.1.2 of [Part1]).
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
skipping to change at page 11, line 21 skipping to change at page 11, line 29
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:
+-------------------+------------------------+ +-------------------+------------------------+
| Header Field Name | Defined in... | | Header Field Name | Defined in... |
+-------------------+------------------------+ +-------------------+------------------------+
| Content-Length | Section 9.2 of [Part1] | | Content-Length | Section 8.2 of [Part1] |
| 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 15, line 16 skipping to change at page 15, line 24
for multiple user's requests. for multiple user's requests.
Server-driven negotiation allows the user agent to specify its Server-driven negotiation allows the user agent to specify its
preferences, but it cannot expect responses to always honour them. preferences, but it cannot expect responses to always honour them.
For example, the origin server might not implement server-driven For example, the origin server might not implement server-driven
negotiation, or it might decide that sending a response that doesn't negotiation, or it might decide that sending a response that doesn't
conform to them is better than sending a 406 (Not Acceptable) conform to them is better than sending a 406 (Not Acceptable)
response. response.
Many of the mechanisms for expressing preferences use quality values Many of the mechanisms for expressing preferences use quality values
to declare relative preference. See Section 6.4 of [Part1] for more to declare relative preference. See Section 5.3 of [Part1] for more
information. information.
HTTP/1.1 includes the following header fields for enabling server- HTTP/1.1 includes the following header fields for enabling server-
driven negotiation through description of user agent capabilities and driven negotiation through description of user agent capabilities and
user preferences: Accept (Section 6.1), Accept-Charset (Section 6.2), user preferences: Accept (Section 6.1), Accept-Charset (Section 6.2),
Accept-Encoding (Section 6.3), Accept-Language (Section 6.4), and Accept-Encoding (Section 6.3), Accept-Language (Section 6.4), and
User-Agent (Section 9.9 of [Part2]). However, an origin server is User-Agent (Section 9.10 of [Part2]). However, an origin server is
not limited to these dimensions and MAY vary the response based on not limited to these dimensions and MAY vary the response based on
any aspect of the request, including aspects of the connection (e.g., any aspect of the request, including aspects of the connection (e.g.,
IP address) or information within extension header fields not defined IP address) or information within extension header fields not defined
by this specification. by this specification.
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
skipping to change at page 16, line 50 skipping to change at page 17, line 10
The asterisk "*" character is used to group media types into ranges, The asterisk "*" character is used to group media types into ranges,
with "*/*" indicating all media types and "type/*" indicating all with "*/*" indicating all media types and "type/*" indicating all
subtypes of that type. The media-range MAY include media type subtypes of that type. The media-range MAY include media type
parameters that are applicable to that range. parameters that are applicable to that range.
Each media-range MAY be followed by one or more accept-params, Each media-range MAY be followed by one or more accept-params,
beginning with the "q" parameter for indicating a relative quality beginning with the "q" parameter for indicating a relative quality
factor. The first "q" parameter (if any) separates the media-range factor. The first "q" parameter (if any) separates the media-range
parameter(s) from the accept-params. Quality factors allow the user parameter(s) from the accept-params. Quality factors allow the user
or user agent to indicate the relative degree of preference for that or user agent to indicate the relative degree of preference for that
media-range, using the qvalue scale from 0 to 1 (Section 6.4 of media-range, using the qvalue scale from 0 to 1 (Section 5.3 of
[Part1]). The default value is q=1. [Part1]). The default value is q=1.
Note: Use of the "q" parameter name to separate media type Note: Use of the "q" parameter name to separate media type
parameters from Accept extension parameters is due to historical parameters from Accept extension parameters is due to historical
practice. Although this prevents any media type parameter named practice. Although this prevents any media type parameter named
"q" from being used with a media range, such an event is believed "q" from being used with a media range, such an event is believed
to be unlikely given the lack of any "q" parameters in the IANA to be unlikely given the lack of any "q" parameters in the IANA
media type registry and the rare usage of any media type media type registry and the rare usage of any media type
parameters in Accept. Future media types are discouraged from parameters in Accept. Future media types are discouraged from
registering any parameter named "q". registering any parameter named "q".
The example The example
Accept: audio/*; q=0.2, audio/basic Accept: audio/*; q=0.2, audio/basic
SHOULD be interpreted as "I prefer audio/basic, but send me any audio SHOULD be interpreted as "I prefer audio/basic, but send me any audio
type if it is the best available after an 80% mark-down in quality". type if it is the best available after an 80% mark-down in quality".
If no Accept header field is present, then it is assumed that the A request without any Accept header field implies that the user agent
client accepts all media types. If an Accept header field is present will accept any media type in response. If an Accept header field is
in a request, but the server cannot send a response which is present in a request and none of the available representations for
acceptable, then the server can either send a response in another the response have a media type that is listed as acceptable, the
format, or a 406 (Not Acceptable) response. origin server MAY either honor the Accept header field by sending a
406 (Not Acceptable) response or disregard the Accept header field by
treating the response as if it is not subject to content negotiation.
A more elaborate example is A more elaborate example is
Accept: text/plain; q=0.5, text/html, Accept: text/plain; q=0.5, text/html,
text/x-dvi; q=0.8, text/x-c text/x-dvi; q=0.8, text/x-c
Verbally, this would be interpreted as "text/html and text/x-c are Verbally, this would be interpreted as "text/html and text/x-c are
the preferred media types, but if they do not exist, then send the the preferred media types, but if they do not exist, then send the
text/x-dvi representation, and if that does not exist, send the text/ text/x-dvi representation, and if that does not exist, send the text/
plain representation". plain representation".
skipping to change at page 19, line 6 skipping to change at page 19, line 16
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 which is not mentioned elsewhere in matches every character encoding which is not mentioned elsewhere in
the Accept-Charset field. If no "*" is present in an Accept-Charset the Accept-Charset field. If no "*" is present in an Accept-Charset
field, then all character encodings not explicitly mentioned get a field, then all character encodings not explicitly mentioned get a
quality value of 0. quality value of 0.
If no Accept-Charset header field is present, the default is that any A request without any Accept-Charset header field implies that the
character encoding is acceptable. If an Accept-Charset header field user agent will accept any character encoding in response. If an
is present in a request, but the server cannot send a response which Accept-Charset header field is present in a request and none of the
is acceptable, then the server can either use another character available representations for the response have a character encoding
encoding, or send a 406 (Not Acceptable) response. that is listed as acceptable, the origin server MAY either honor the
Accept-Charset header field by sending a 406 (Not Acceptable)
response or disregard the Accept-Charset header field by treating the
response as if it is not subject to content negotiation.
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. An "identity" token is used as a synonym for "no
encoding" in order to communicate when no encoding is preferred.
Accept-Encoding = #( codings [ OWS ";" OWS "q=" qvalue ] ) Accept-Encoding = #( codings [ OWS ";" OWS "q=" qvalue ] )
codings = ( content-coding / "*" ) codings = content-coding / "identity" / "*"
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: For example,
Accept-Encoding: compress, gzip Accept-Encoding: compress, gzip
Accept-Encoding: Accept-Encoding:
Accept-Encoding: * Accept-Encoding: *
Accept-Encoding: compress;q=0.5, gzip;q=1.0 Accept-Encoding: compress;q=0.5, gzip;q=1.0
Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0 Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0
A server tests whether a content-coding is acceptable, according to A server tests whether a content-coding for a given representation is
an Accept-Encoding field, using these rules: acceptable, according to an Accept-Encoding field, using these rules:
1. If the content-coding is one of the content-codings listed in the
Accept-Encoding field, then it is acceptable, unless it is
accompanied by a qvalue of 0. (As defined in Section 6.4 of
[Part1], a qvalue of 0 means "not acceptable".)
2. The special "*" symbol in an Accept-Encoding field matches any 1. The special "*" symbol in an Accept-Encoding field matches any
available content-coding not explicitly listed in the header available content-coding not explicitly listed in the header
field. field.
3. If multiple content-codings are acceptable, then the acceptable 2. If the representation has no content-coding, then it is
content-coding with the highest non-zero qvalue is preferred. acceptable by default unless specifically excluded by the Accept-
Encoding field stating either "identity;q=0" or "*;q=0" without a
more specific entry for "identity".
4. The "identity" content-coding is always acceptable, unless 3. If the representation's content-coding is one of the content-
specifically refused because the Accept-Encoding field includes codings listed in the Accept-Encoding field, then it is
"identity;q=0", or because the field includes "*;q=0" and does acceptable unless it is accompanied by a qvalue of 0. (As
not explicitly include the "identity" content-coding. If the defined in Section 5.3 of [Part1], a qvalue of 0 means "not
Accept-Encoding field-value is empty, then only the "identity" acceptable".)
encoding is acceptable.
If an Accept-Encoding field is present in a request, but the server 4. If multiple content-codings are acceptable, then the acceptable
cannot send a response which is acceptable, then the server SHOULD content-coding with the highest non-zero qvalue is preferred.
send a response without any encoding (i.e., the "identity" encoding).
If no Accept-Encoding field is present in a request, the server MAY An Accept-Encoding header field with a combined field-value that is
assume that the client will accept any content coding. In this case, empty implies that the user agent does not want any content-coding in
if "identity" is one of the available content-codings, then the response. If an Accept-Encoding header field is present in a request
server SHOULD use the "identity" content-coding, unless it has and none of the available representations for the response have a
additional information that a different content-coding is meaningful content-coding that is listed as acceptable, the origin server SHOULD
to the client. send a response without any content-coding.
Note: If the request does not include an Accept-Encoding field, A request without an Accept-Encoding header field implies that the
and if the "identity" content-coding is unavailable, then content- user agent will accept any content-coding in response, but a
codings commonly understood by HTTP/1.0 clients (i.e., "gzip" and representation without content-coding is preferred for compatibility
"compress") are preferred; some older clients improperly display with the widest variety of user agents.
messages sent with other content-codings. The server might also
make this decision based on information about the particular user-
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" 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.
skipping to change at page 21, line 34 skipping to change at page 21, line 40
familiar with the details of language matching as described above, familiar with the details of language matching as described above,
and ought to be provided appropriate guidance. As an example, and ought to be provided appropriate guidance. As an example,
users might assume that on selecting "en-gb", they will be served users might assume that on selecting "en-gb", they will be served
any kind of English document if British English is not available. any kind of English document if British English is not available.
A user agent might suggest in such a case to add "en" to get the A user agent might suggest in such a case to add "en" to get the
best matching behavior. best matching behavior.
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 beyond those inherent in the
mechanisms must be applied in order to obtain the media-type media type, and thus what decoding mechanisms must be applied in
referenced by the Content-Type header field. Content-Encoding is order to obtain the media-type referenced by the Content-Type header
primarily used to allow a representation to be compressed without field. Content-Encoding is primarily used to allow a representation
losing the identity of its underlying media type. to be compressed without losing the identity of its underlying media
type.
Content-Encoding = 1#content-coding Content-Encoding = 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"
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 media type includes an inherent encoding, such as a data
representation metadata MUST include a Content-Encoding header field format that is always compressed, then that encoding would not be
(Section 6.5) that lists the non-identity content-coding(s) used. restated as a Content-Encoding even if it happens to be the same
algorithm as one of the content-codings. Such a content-coding would
only be listed if, for some bizarre reason, it is applied a second
time to form the representation. Likewise, an origin server might
choose to publish the same payload data as multiple representations
that differ only in whether the coding is defined as part of Content-
Type or Content-Encoding, since some user agents will behave
differently in their handling of each response (e.g., open a "Save as
..." dialog instead of automatic decompression and rendering of
content).
If the content-coding of a representation in a request message is not A representation that has a content-coding applied to it MUST include
acceptable to the origin server, the server SHOULD respond with a a Content-Encoding header field (Section 6.5) that lists the content-
status code of 415 (Unsupported Media Type). coding(s) applied.
If multiple encodings have been applied to a representation, the If multiple encodings have been applied to a representation, the
content codings MUST be listed in the order in which they were content codings MUST be listed in the order in which they were
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.
If the content-coding of a representation in a request message is not
acceptable to the origin server, the server SHOULD respond with a
status code of 415 (Unsupported Media Type).
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 = 1#language-tag Content-Language = 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
skipping to change at page 25, line 40 skipping to change at page 26, line 11
Section 2.2.1 of this document. Section 2.2.1 of this document.
The HTTP Content Codings Registry located at The HTTP Content Codings Registry located at
<http://www.iana.org/assignments/http-parameters> shall be updated <http://www.iana.org/assignments/http-parameters> shall be updated
with the registration below: with the registration below:
+----------+-----------------------------------------+--------------+ +----------+-----------------------------------------+--------------+
| Name | Description | Reference | | Name | Description | Reference |
+----------+-----------------------------------------+--------------+ +----------+-----------------------------------------+--------------+
| compress | UNIX "compress" program method | Section | | compress | UNIX "compress" program method | Section |
| | | 6.2.2.1 of | | | | 5.1.2.1 of |
| | | [Part1] | | | | [Part1] |
| deflate | "deflate" compression mechanism | Section | | deflate | "deflate" compression mechanism | Section |
| | ([RFC1951]) used inside the "zlib" data | 6.2.2.2 of | | | ([RFC1951]) used inside the "zlib" data | 5.1.2.2 of |
| | format ([RFC1950]) | [Part1] | | | format ([RFC1950]) | [Part1] |
| gzip | Same as GNU zip [RFC1952] | Section | | gzip | Same as GNU zip [RFC1952] | Section |
| | | 6.2.2.3 of | | | | 5.1.2.3 of |
| | | [Part1] | | | | [Part1] |
| identity | No transformation | Section 2.2 | | identity | reserved (synonym for "no encoding" in | Section 6.3 |
| | Accept-Encoding header field) | |
+----------+-----------------------------------------+--------------+ +----------+-----------------------------------------+--------------+
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.
skipping to change at page 26, line 50 skipping to change at page 27, line 20
identifier. In environments where proxies are used to enhance identifier. In environments where proxies are used to enhance
privacy, user agents ought to be conservative in offering accept privacy, user agents ought to be conservative in offering accept
header configuration options to end users. As an extreme privacy header configuration options to end users. As an extreme privacy
measure, proxies could filter the accept header fields in relayed measure, proxies could filter the accept header fields in relayed
requests. General purpose user agents which provide a high degree of requests. General purpose user agents which provide a high degree of
header configurability SHOULD warn users about the loss of privacy header configurability SHOULD warn users about the loss of privacy
which can be involved. which can be involved.
9. Acknowledgments 9. Acknowledgments
See Section 12 of [Part1]. See Section 11 of [Part1].
10. References 10. References
10.1. Normative References 10.1. Normative References
[Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
and Message Parsing", draft-ietf-httpbis-p1-messaging-16 and Message Parsing", draft-ietf-httpbis-p1-messaging-17
(work in progress), August 2011. (work in progress), October 2011.
[Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 2: Message and J. Reschke, Ed., "HTTP/1.1, part 2: Message
Semantics", draft-ietf-httpbis-p2-semantics-16 (work in Semantics", draft-ietf-httpbis-p2-semantics-17 (work in
progress), August 2011. progress), October 2011.
[Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional
Requests", draft-ietf-httpbis-p4-conditional-16 (work in Requests", draft-ietf-httpbis-p4-conditional-17 (work in
progress), August 2011. progress), October 2011.
[Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and
Partial Responses", draft-ietf-httpbis-p5-range-16 (work Partial Responses", draft-ietf-httpbis-p5-range-17 (work
in progress), August 2011. in progress), October 2011.
[Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part
6: Caching", draft-ietf-httpbis-p6-cache-16 (work in 6: Caching", draft-ietf-httpbis-p6-cache-17 (work in
progress), August 2011. progress), October 2011.
[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format
Specification version 3.3", RFC 1950, May 1996. Specification version 3.3", RFC 1950, May 1996.
RFC 1950 is an Informational RFC, thus it might be less RFC 1950 is an Informational RFC, thus it might be less
stable than this specification. On the other hand, this stable than this specification. On the other hand, this
downward reference was present since the publication of downward reference was present since the publication of
RFC 2068 in 1997 ([RFC2068]), therefore it is unlikely to RFC 2068 in 1997, therefore it is unlikely to cause
cause problems in practice. See also [BCP97]. problems in practice. See also [BCP97].
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification
version 1.3", RFC 1951, May 1996. version 1.3", RFC 1951, May 1996.
RFC 1951 is an Informational RFC, thus it might be less RFC 1951 is an Informational RFC, thus it might be less
stable than this specification. On the other hand, this stable than this specification. On the other hand, this
downward reference was present since the publication of downward reference was present since the publication of
RFC 2068 in 1997 ([RFC2068]), therefore it is unlikely to RFC 2068 in 1997, therefore it is unlikely to cause
cause problems in practice. See also [BCP97]. problems in practice. See also [BCP97].
[RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G. [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G.
Randers-Pehrson, "GZIP file format specification version Randers-Pehrson, "GZIP file format specification version
4.3", RFC 1952, May 1996. 4.3", RFC 1952, May 1996.
RFC 1952 is an Informational RFC, thus it might be less RFC 1952 is an Informational RFC, thus it might be less
stable than this specification. On the other hand, this stable than this specification. On the other hand, this
downward reference was present since the publication of downward reference was present since the publication of
RFC 2068 in 1997 ([RFC2068]), therefore it is unlikely to RFC 2068 in 1997, therefore it is unlikely to cause
cause problems in practice. See also [BCP97]. problems in practice. See also [BCP97].
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996. Bodies", RFC 2045, November 1996.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996. November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 31, line 21 skipping to change at page 31, line 37
octets 13 and 10 to represent CR and LF, respectively, as is the case octets 13 and 10 to represent CR and LF, respectively, as is the case
for some multi-byte character encodings. 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 8 of [Part2])
[Part1]) to simplify the process of date comparison. Proxies and to simplify the process of date comparison. Proxies and gateways
gateways from other protocols SHOULD ensure that any Date header from other protocols SHOULD ensure that any Date header field present
field present in a message conforms to one of the HTTP/1.1 formats in a message conforms to one of the HTTP/1.1 formats and rewrite the
and rewrite the date if necessary. date if necessary.
A.4. Introduction of Content-Encoding A.4. Introduction of Content-Encoding
MIME does not include any concept equivalent to HTTP/1.1's Content- MIME does not include any concept equivalent to HTTP/1.1's Content-
Encoding header field. Since this acts as a modifier on the media Encoding header field. Since this acts as a modifier on the media
type, proxies and gateways from HTTP to MIME-compliant protocols MUST type, proxies and gateways from HTTP to MIME-compliant protocols MUST
either change the value of the Content-Type header field or decode either change the value of the Content-Type header field or decode
the representation before forwarding the message. (Some experimental the representation before forwarding the message. (Some experimental
applications of Content-Type for Internet mail have used a media-type applications of Content-Type for Internet mail have used a media-type
parameter of ";conversions=<content-coding>" to perform a function parameter of ";conversions=<content-coding>" to perform a function
skipping to change at page 32, line 7 skipping to change at page 32, line 23
Proxies and gateways from HTTP to MIME-compliant protocols are Proxies and gateways from HTTP to MIME-compliant protocols are
responsible for ensuring that the message is in the correct format responsible for ensuring that the message is in the correct format
and encoding for safe transport on that protocol, where "safe and encoding for safe transport on that protocol, where "safe
transport" is defined by the limitations of the protocol being used. transport" is defined by the limitations of the protocol being used.
Such a proxy or gateway SHOULD label the data with an appropriate Such a proxy or gateway SHOULD label the data with an appropriate
Content-Transfer-Encoding if doing so will improve the likelihood of Content-Transfer-Encoding if doing so will improve the likelihood of
safe transport over the destination protocol. safe transport over the destination protocol.
A.6. Introduction of Transfer-Encoding A.6. Introduction of Transfer-Encoding
HTTP/1.1 introduces the Transfer-Encoding header field (Section 9.7 HTTP/1.1 introduces the Transfer-Encoding header field (Section 8.6
of [Part1]). Proxies/gateways MUST remove any transfer-coding prior of [Part1]). Proxies/gateways MUST remove any transfer-coding prior
to forwarding a message via a MIME-compliant protocol. to forwarding a message via a MIME-compliant protocol.
A.7. MHTML and Line Length Limitations A.7. MHTML and Line Length Limitations
HTTP implementations which share code with MHTML [RFC2557] HTTP implementations which share code with MHTML [RFC2557]
implementations need to be aware of MIME line length limitations. implementations need to be aware of MIME line length limitations.
Since HTTP does not have this limitation, HTTP does not fold long Since HTTP does not have this limitation, HTTP does not fold long
lines. MHTML messages being transported by HTTP follow all lines. MHTML messages being transported by HTTP follow all
conventions of MHTML, including line length limitations and folding, conventions of MHTML, including line length limitations and folding,
skipping to change at page 33, line 48 skipping to change at page 34, line 16
MIME-Version = 1*DIGIT "." 1*DIGIT MIME-Version = 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.7> absolute-URI = <absolute-URI, defined in [Part1], Section 2.7>
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 / "identity" / "*"
content-coding = token content-coding = token
language-range = <language-range, defined in [RFC4647], Section 2.1> language-range = <language-range, defined in [RFC4647], Section 2.1>
language-tag = <Language-Tag, defined in [RFC5646], Section 2.1> language-tag = <Language-Tag, defined in [RFC5646], Section 2.1>
media-range = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS media-range = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS
";" OWS parameter ) ";" OWS parameter )
media-type = type "/" subtype *( OWS ";" OWS parameter ) media-type = type "/" subtype *( OWS ";" OWS parameter )
parameter = attribute "=" value parameter = attribute "=" value
partial-URI = <partial-URI, defined in [Part1], Section 2.7> partial-URI = <partial-URI, defined in [Part1], Section 2.7>
qvalue = <qvalue, defined in [Part1], Section 6.4> qvalue = <qvalue, defined in [Part1], Section 5.3>
subtype = token subtype = token
token = <token, defined in [Part1], Section 3.2.3> token = <token, defined in [Part1], Section 3.2.3>
type = token type = token
value = word value = word
word = <word, defined in [Part1], Section 3.2.3> word = <word, defined in [Part1], Section 3.2.3>
skipping to change at page 40, line 28 skipping to change at page 41, line 5
None. None.
E.17. Since draft-ietf-httpbis-p3-payload-15 E.17. Since draft-ietf-httpbis-p3-payload-15
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/285>: "Strength of o <http://tools.ietf.org/wg/httpbis/trac/ticket/285>: "Strength of
requirements on Accept re: 406" requirements on Accept re: 406"
E.18. Since draft-ietf-httpbis-p3-payload-16
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/186>: "Document
HTTP's error-handling philosophy"
Index Index
A A
Accept header field 16 Accept header field 16
Accept-Charset header field 18 Accept-Charset header field 18
Accept-Encoding header field 19 Accept-Encoding header field 19
Accept-Language header field 20 Accept-Language header field 20
C C
Coding Format Coding Format
compress 7 compress 7
deflate 7 deflate 7
gzip 7 gzip 8
identity 7
compress (Coding Format) 7 compress (Coding Format) 7
content negotiation 5 content negotiation 5
Content-Encoding header field 21 Content-Encoding header field 21
Content-Language header field 22 Content-Language header field 22
Content-Location header field 23 Content-Location header field 23
Content-Type header field 24 Content-Type header field 25
D D
deflate (Coding Format) 7 deflate (Coding Format) 7
G G
Grammar Grammar
Accept 16 Accept 16
Accept-Charset 18 Accept-Charset 18
Accept-Encoding 19 Accept-Encoding 19
accept-ext 16 accept-ext 16
Accept-Language 20 Accept-Language 20
accept-params 16 accept-params 16
attribute 8 attribute 8
charset 6 charset 7
codings 19 codings 19
content-coding 7 content-coding 7
Content-Encoding 21 Content-Encoding 21
Content-Language 22 Content-Language 22
Content-Location 23 Content-Location 23
Content-Type 24 Content-Type 25
language-range 20 language-range 20
language-tag 10 language-tag 10
media-range 16 media-range 16
media-type 8 media-type 8
MIME-Version 30 MIME-Version 30
parameter 8 parameter 8
subtype 8 subtype 8
type 8 type 8
value 8 value 8
gzip (Coding Format) 7 gzip (Coding Format) 8
H H
Header Fields Header Fields
Accept 16 Accept 16
Accept-Charset 18 Accept-Charset 18
Accept-Encoding 19 Accept-Encoding 19
Accept-Language 20 Accept-Language 20
Content-Encoding 21 Content-Encoding 21
Content-Language 22 Content-Language 22
Content-Location 23 Content-Location 23
Content-Type 24 Content-Type 25
MIME-Version 30 MIME-Version 30
I
identity (Coding Format) 7
M M
MIME-Version header field 30 MIME-Version header field 30
P P
payload 10 payload 11
R R
representation 11 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
 End of changes. 74 change blocks. 
151 lines changed or deleted 177 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/