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/ |