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