draft-ietf-httpbis-p3-payload-05.txt | draft-ietf-httpbis-p3-payload-06.txt | |||
---|---|---|---|---|
Network Working Group R. Fielding, Ed. | HTTPbis Working Group R. Fielding, Ed. | |||
Internet-Draft Day Software | Internet-Draft Day Software | |||
Obsoletes: 2616 (if approved) J. Gettys | Obsoletes: 2616 (if approved) J. Gettys | |||
Intended status: Standards Track One Laptop per Child | Intended status: Standards Track One Laptop per Child | |||
Expires: May 20, 2009 J. Mogul | Expires: September 10, 2009 J. Mogul | |||
HP | HP | |||
H. Frystyk | H. Frystyk | |||
Microsoft | Microsoft | |||
L. Masinter | L. Masinter | |||
Adobe Systems | Adobe Systems | |||
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 | |||
November 16, 2008 | March 9, 2009 | |||
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-05 | draft-ietf-httpbis-p3-payload-06 | |||
Status of this Memo | Status of this Memo | |||
By submitting this Internet-Draft, each author represents that any | This Internet-Draft is submitted to IETF in full conformance with the | |||
applicable patent or other IPR claims of which he or she is aware | provisions of BCP 78 and BCP 79. This document may contain material | |||
have been or will be disclosed, and any of which he or she becomes | from IETF Documents or IETF Contributions published or made publicly | |||
aware will be disclosed, in accordance with Section 6 of BCP 79. | available before November 10, 2008. The person(s) controlling the | |||
copyright in some of this material may not have granted the IETF | ||||
Trust the right to allow modifications of such material outside the | ||||
IETF Standards Process. Without obtaining an adequate license from | ||||
the person(s) controlling the copyright in such materials, this | ||||
document may not be modified outside the IETF Standards Process, and | ||||
derivative works of it may not be created outside the IETF Standards | ||||
Process, except to format it for publication as an RFC or to | ||||
translate it into languages other than English. | ||||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
other groups may also distribute working documents as Internet- | other groups may also distribute working documents as Internet- | |||
Drafts. | Drafts. | |||
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." | |||
skipping to change at page 1, line 42 | skipping to change at page 2, line 4 | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
other groups may also distribute working documents as Internet- | other groups may also distribute working documents as Internet- | |||
Drafts. | Drafts. | |||
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." | |||
The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
This Internet-Draft will expire on May 20, 2009. | This Internet-Draft will expire on September 10, 2009. | |||
Copyright Notice | ||||
Copyright (c) 2009 IETF Trust and the persons identified as the | ||||
document authors. All rights reserved. | ||||
This document is subject to BCP 78 and the IETF Trust's Legal | ||||
Provisions Relating to IETF Documents in effect on the date of | ||||
publication of this document (http://trustee.ietf.org/license-info). | ||||
Please review these documents carefully, as they describe your rights | ||||
and restrictions with respect to this document. | ||||
Abstract | Abstract | |||
The Hypertext Transfer Protocol (HTTP) is an application-level | The Hypertext Transfer Protocol (HTTP) is an application-level | |||
protocol for distributed, collaborative, hypermedia information | protocol for distributed, collaborative, hypermedia information | |||
systems. HTTP has been in use by the World Wide Web global | systems. HTTP has been in use by the World Wide Web global | |||
information initiative since 1990. This document is Part 3 of the | information initiative since 1990. This document is Part 3 of the | |||
seven-part specification that defines the protocol referred to as | seven-part specification that defines the protocol referred to as | |||
"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 3 defines | "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 3 defines | |||
HTTP message content, metadata, and content negotiation. | HTTP message content, metadata, and content negotiation. | |||
Editorial Note (To be removed by RFC Editor) | Editorial Note (To be removed by RFC Editor) | |||
Discussion of this draft should take place on the HTTPBIS working | Discussion of this draft should take place on the HTTPBIS working | |||
group mailing list (ietf-http-wg@w3.org). The current issues list is | group mailing list (ietf-http-wg@w3.org). The current issues list is | |||
at <http://tools.ietf.org/wg/httpbis/trac/report/11> and related | at <http://tools.ietf.org/wg/httpbis/trac/report/11> 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 D.6. | The changes in this draft are summarized in Appendix E.7. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 | 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
2. Notational Conventions and Generic Grammar . . . . . . . . . . 5 | 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5 | |||
3. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 6 | 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 6 | |||
3.1. Character Sets . . . . . . . . . . . . . . . . . . . . . . 6 | 1.2.2. ABNF Rules defined in other Parts of the | |||
3.1.1. Missing Charset . . . . . . . . . . . . . . . . . . . 7 | Specification . . . . . . . . . . . . . . . . . . . . 6 | |||
3.2. Content Codings . . . . . . . . . . . . . . . . . . . . . 7 | 2. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 6 | |||
3.3. Media Types . . . . . . . . . . . . . . . . . . . . . . . 8 | 2.1. Character Sets . . . . . . . . . . . . . . . . . . . . . . 6 | |||
3.3.1. Canonicalization and Text Defaults . . . . . . . . . . 9 | 2.1.1. Missing Charset . . . . . . . . . . . . . . . . . . . 7 | |||
3.3.2. Multipart Types . . . . . . . . . . . . . . . . . . . 10 | 2.2. Content Codings . . . . . . . . . . . . . . . . . . . . . 7 | |||
3.4. Quality Values . . . . . . . . . . . . . . . . . . . . . . 11 | 2.3. Media Types . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
3.5. Language Tags . . . . . . . . . . . . . . . . . . . . . . 11 | 2.3.1. Canonicalization and Text Defaults . . . . . . . . . . 9 | |||
4. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 | 2.3.2. Multipart Types . . . . . . . . . . . . . . . . . . . 10 | |||
4.1. Entity Header Fields . . . . . . . . . . . . . . . . . . . 12 | 2.4. Language Tags . . . . . . . . . . . . . . . . . . . . . . 11 | |||
4.2. Entity Body . . . . . . . . . . . . . . . . . . . . . . . 12 | 3. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
4.2.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 13 | 3.1. Entity Header Fields . . . . . . . . . . . . . . . . . . . 12 | |||
4.2.2. Entity Length . . . . . . . . . . . . . . . . . . . . 13 | 3.2. Entity Body . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
5. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 13 | 3.2.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
5.1. Server-driven Negotiation . . . . . . . . . . . . . . . . 14 | 3.2.2. Entity Length . . . . . . . . . . . . . . . . . . . . 13 | |||
5.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . . 15 | 4. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 13 | |||
5.3. Transparent Negotiation . . . . . . . . . . . . . . . . . 16 | 4.1. Server-driven Negotiation . . . . . . . . . . . . . . . . 14 | |||
6. Header Field Definitions . . . . . . . . . . . . . . . . . . . 16 | 4.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . . 15 | |||
6.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . . 16 | 4.3. Transparent Negotiation . . . . . . . . . . . . . . . . . 15 | |||
6.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . . 18 | 5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 16 | |||
6.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 19 | 5.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
6.4. Accept-Language . . . . . . . . . . . . . . . . . . . . . 20 | 5.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . . 18 | |||
6.5. Content-Encoding . . . . . . . . . . . . . . . . . . . . . 22 | 5.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 19 | |||
6.6. Content-Language . . . . . . . . . . . . . . . . . . . . . 23 | 5.4. Accept-Language . . . . . . . . . . . . . . . . . . . . . 20 | |||
6.7. Content-Location . . . . . . . . . . . . . . . . . . . . . 24 | 5.5. Content-Encoding . . . . . . . . . . . . . . . . . . . . . 22 | |||
6.8. Content-MD5 . . . . . . . . . . . . . . . . . . . . . . . 24 | 5.6. Content-Language . . . . . . . . . . . . . . . . . . . . . 23 | |||
6.9. Content-Type . . . . . . . . . . . . . . . . . . . . . . . 26 | 5.7. Content-Location . . . . . . . . . . . . . . . . . . . . . 23 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 | 5.8. Content-MD5 . . . . . . . . . . . . . . . . . . . . . . . 24 | |||
7.1. Message Header Registration . . . . . . . . . . . . . . . 26 | 5.9. Content-Type . . . . . . . . . . . . . . . . . . . . . . . 26 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 27 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 | |||
8.1. Privacy Issues Connected to Accept Headers . . . . . . . . 27 | 6.1. Message Header Registration . . . . . . . . . . . . . . . 26 | |||
8.2. Content-Disposition Issues . . . . . . . . . . . . . . . . 28 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 | |||
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 | 7.1. Privacy Issues Connected to Accept Headers . . . . . . . . 27 | |||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 | 7.2. Content-Disposition Issues . . . . . . . . . . . . . . . . 27 | |||
10.1. Normative References . . . . . . . . . . . . . . . . . . . 28 | 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 | |||
10.2. Informative References . . . . . . . . . . . . . . . . . . 30 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 | |||
9.1. Normative References . . . . . . . . . . . . . . . . . . . 28 | ||||
9.2. Informative References . . . . . . . . . . . . . . . . . . 30 | ||||
Appendix A. Differences Between HTTP Entities and RFC 2045 | Appendix A. Differences Between HTTP Entities and RFC 2045 | |||
Entities . . . . . . . . . . . . . . . . . . . . . . 31 | Entities . . . . . . . . . . . . . . . . . . . . . . 31 | |||
A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 31 | A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 31 | |||
A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 32 | A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 31 | |||
A.3. Introduction of Content-Encoding . . . . . . . . . . . . . 32 | A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 32 | |||
A.4. No Content-Transfer-Encoding . . . . . . . . . . . . . . . 32 | A.4. Introduction of Content-Encoding . . . . . . . . . . . . . 32 | |||
A.5. Introduction of Transfer-Encoding . . . . . . . . . . . . 33 | A.5. No Content-Transfer-Encoding . . . . . . . . . . . . . . . 32 | |||
A.6. MHTML and Line Length Limitations . . . . . . . . . . . . 33 | A.6. Introduction of Transfer-Encoding . . . . . . . . . . . . 33 | |||
A.7. MHTML and Line Length Limitations . . . . . . . . . . . . 33 | ||||
Appendix B. Additional Features . . . . . . . . . . . . . . . . . 33 | Appendix B. Additional Features . . . . . . . . . . . . . . . . . 33 | |||
B.1. Content-Disposition . . . . . . . . . . . . . . . . . . . 33 | B.1. Content-Disposition . . . . . . . . . . . . . . . . . . . 33 | |||
Appendix C. Compatibility with Previous Versions . . . . . . . . 34 | Appendix C. Compatibility with Previous Versions . . . . . . . . 34 | |||
C.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 34 | C.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 34 | |||
C.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 35 | C.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 35 | |||
Appendix D. Change Log (to be removed by RFC Editor before | Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 35 | |||
publication) . . . . . . . . . . . . . . . . . . . . 35 | Appendix E. Change Log (to be removed by RFC Editor before | |||
D.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 35 | publication) . . . . . . . . . . . . . . . . . . . . 37 | |||
D.2. Since draft-ietf-httpbis-p3-payload-00 . . . . . . . . . . 35 | E.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 37 | |||
D.3. Since draft-ietf-httpbis-p3-payload-01 . . . . . . . . . . 36 | E.2. Since draft-ietf-httpbis-p3-payload-00 . . . . . . . . . . 37 | |||
D.4. Since draft-ietf-httpbis-p3-payload-02 . . . . . . . . . . 36 | E.3. Since draft-ietf-httpbis-p3-payload-01 . . . . . . . . . . 38 | |||
D.5. Since draft-ietf-httpbis-p3-payload-03 . . . . . . . . . . 36 | E.4. Since draft-ietf-httpbis-p3-payload-02 . . . . . . . . . . 38 | |||
D.6. Since draft-ietf-httpbis-p3-payload-04 . . . . . . . . . . 37 | E.5. Since draft-ietf-httpbis-p3-payload-03 . . . . . . . . . . 38 | |||
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 | E.6. Since draft-ietf-httpbis-p3-payload-04 . . . . . . . . . . 39 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 | E.7. Since draft-ietf-httpbis-p3-payload-05 . . . . . . . . . . 39 | |||
Intellectual Property and Copyright Statements . . . . . . . . . . 43 | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 | ||||
1. Introduction | 1. Introduction | |||
This document defines HTTP/1.1 message payloads (a.k.a., content), | This document defines HTTP/1.1 message payloads (a.k.a., content), | |||
the associated metadata header fields that define how the payload is | the associated metadata header fields that define how the payload is | |||
intended to be interpreted by a recipient, the request header fields | intended to be interpreted by a recipient, the request header fields | |||
that may influence content selection, and the various selection | that may 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 39 | skipping to change at page 5, line 39 | |||
An implementation is not compliant if it fails to satisfy one or more | An implementation is not compliant if it fails to satisfy one or more | |||
of the MUST or REQUIRED level requirements for the protocols it | of the MUST or REQUIRED level requirements for the protocols it | |||
implements. An implementation that satisfies all the MUST or | implements. An implementation that satisfies all the MUST or | |||
REQUIRED level and all the SHOULD level requirements for its | REQUIRED level and all the SHOULD level requirements for its | |||
protocols is said to be "unconditionally compliant"; one that | protocols is said to be "unconditionally compliant"; one that | |||
satisfies all the MUST level requirements but not all the SHOULD | satisfies all the MUST level requirements but not all the SHOULD | |||
level requirements for its protocols is said to be "conditionally | level requirements for its protocols is said to be "conditionally | |||
compliant." | compliant." | |||
2. Notational Conventions and Generic Grammar | 1.2. Syntax Notation | |||
This specification uses the ABNF syntax defined in Section 2.1 of | This specification uses the ABNF syntax defined in Section 1.2 of | |||
[Part1] and the core rules defined in Section 2.2 of [Part1]: | [Part1] (which extends the syntax defined in [RFC5234] with a list | |||
rule). Appendix D shows the collected ABNF, with the list rule | ||||
expanded. | ||||
ALPHA = <ALPHA, defined in [Part1], Section 2.2> | The following core rules are included by reference, as defined in | |||
DIGIT = <DIGIT, defined in [Part1], Section 2.2> | [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF | |||
OCTET = <OCTET, defined in [Part1], Section 2.2> | (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 | ||||
sequence of data), SP (space), VCHAR (any visible USASCII character), | ||||
and WSP (whitespace). | ||||
1.2.1. Core Rules | ||||
The core rules below are defined in Section 1.2.2 of [Part1]: | ||||
quoted-string = <quoted-string, defined in [Part1], Section 1.2.2> | ||||
token = <token, defined in [Part1], Section 1.2.2> | ||||
OWS = <OWS, defined in [Part1], Section 1.2.2> | ||||
1.2.2. ABNF Rules defined in other Parts of the Specification | ||||
quoted-string = <quoted-string, defined in [Part1], Section 2.2> | ||||
token = <token, defined in [Part1], Section 2.2> | ||||
OWS = <OWS, defined in [Part1], Section 2.2> | ||||
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 3.2> | absolute-URI = <absolute-URI, defined in [Part1], Section 2.1> | |||
Content-Length = <Content-Length, defined in [Part1], Section 8.2> | Content-Length = <Content-Length, defined in [Part1], Section 8.2> | |||
relativeURI = <relativeURI, defined in [Part1], Section 3.2> | ||||
message-header = <message-header, defined in [Part1], Section 4.2> | message-header = <message-header, defined in [Part1], Section 4.2> | |||
partial-URI = <partial-URI, defined in [Part1], Section 2.1> | ||||
qvalue = <qvalue, defined in [Part1], Section 3.5> | ||||
Last-Modified = <Last-Modified, defined in [Part4], Section 7.6> | Last-Modified = <Last-Modified, defined in [Part4], Section 6.6> | |||
Content-Range = <Content-Range, defined in [Part5], Section 6.2> | Content-Range = <Content-Range, defined in [Part5], Section 5.2> | |||
Expires = <Expires, defined in [Part6], Section 16.3> | Expires = <Expires, defined in [Part6], Section 3.3> | |||
3. Protocol Parameters | 2. Protocol Parameters | |||
3.1. Character Sets | 2.1. Character Sets | |||
HTTP uses the same definition of the term "character set" as that | HTTP uses the same definition of the term "character set" as that | |||
described for MIME: | described for MIME: | |||
The term "character set" is used in this document to refer to a | The term "character set" is used in this document to refer to a | |||
method used with one or more tables to convert a sequence of octets | method used with one or more tables to convert a sequence of octets | |||
into a sequence of characters. Note that unconditional conversion in | into a sequence of characters. Note that unconditional conversion in | |||
the other direction is not required, in that not all characters may | the other direction is not required, in that not all characters may | |||
be available in a given character set and a character set may provide | be available in a given character set and a character set may provide | |||
more than one sequence of octets to represent a particular character. | more than one sequence of octets to represent a particular character. | |||
skipping to change at page 7, line 19 | skipping to change at page 7, line 31 | |||
HTTP uses charset in two contexts: within an Accept-Charset request | HTTP uses charset in two contexts: within an Accept-Charset request | |||
header (in which the charset value is an unquoted token) and as the | header (in which the charset value is an unquoted token) and as the | |||
value of a parameter in a Content-Type header (within a request or | value of a parameter in a Content-Type header (within a request or | |||
response), in which case the parameter value of the charset parameter | response), in which case the parameter value of the charset parameter | |||
may be quoted. | may be quoted. | |||
Implementors should be aware of IETF character set requirements | Implementors should be aware of IETF character set requirements | |||
[RFC3629] [RFC2277]. | [RFC3629] [RFC2277]. | |||
3.1.1. Missing Charset | 2.1.1. Missing Charset | |||
Some HTTP/1.0 software has interpreted a Content-Type header without | Some HTTP/1.0 software has interpreted a Content-Type header without | |||
charset parameter incorrectly to mean "recipient should guess." | charset parameter incorrectly to mean "recipient should guess." | |||
Senders wishing to defeat this behavior MAY include a charset | Senders wishing to defeat this behavior MAY include a charset | |||
parameter even when the charset is ISO-8859-1 ([ISO-8859-1]) and | 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. | 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 | Unfortunately, some older HTTP/1.0 clients did not deal properly with | |||
an explicit charset parameter. HTTP/1.1 recipients MUST respect the | an explicit charset parameter. HTTP/1.1 recipients MUST respect the | |||
charset label provided by the sender; and those user agents that have | charset label provided by the sender; and those user agents that have | |||
a provision to "guess" a charset MUST use the charset from the | a provision to "guess" a charset MUST use the charset from the | |||
content-type field if they support that charset, rather than the | content-type field if they support that charset, rather than the | |||
recipient's preference, when initially displaying a document. See | recipient's preference, when initially displaying a document. See | |||
Section 3.3.1. | Section 2.3.1. | |||
3.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 an entity. Content codings are primarily | been or can be applied to an entity. Content codings are primarily | |||
used to allow a document to be compressed or otherwise usefully | used to allow a document to be compressed or otherwise usefully | |||
transformed without losing the identity of its underlying media type | transformed without losing the identity of its underlying media type | |||
and without loss of information. Frequently, the entity is stored in | and without loss of information. Frequently, the entity is stored in | |||
coded form, transmitted directly, and only decoded by the recipient. | coded form, transmitted directly, and only decoded by the recipient. | |||
content-coding = token | content-coding = token | |||
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 5.3) and | |||
Content-Encoding (Section 6.5) header fields. Although the value | Content-Encoding (Section 5.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. | |||
The Internet Assigned Numbers Authority (IANA) acts as a registry for | The Internet Assigned Numbers Authority (IANA) acts as a registry for | |||
content-coding value tokens. Initially, the registry contains the | content-coding value tokens. Initially, the registry contains the | |||
following tokens: | following tokens: | |||
gzip | gzip | |||
skipping to change at page 8, line 46 | skipping to change at page 9, line 9 | |||
whatsoever. This content-coding is used only in the Accept- | whatsoever. This content-coding is used only in the Accept- | |||
Encoding header, and SHOULD NOT be used in the Content-Encoding | Encoding header, and SHOULD NOT be used in the Content-Encoding | |||
header. | header. | |||
New content-coding value tokens SHOULD be registered; to allow | New content-coding value tokens SHOULD be registered; to allow | |||
interoperability between clients and servers, specifications of the | interoperability between clients and servers, specifications of the | |||
content coding algorithms needed to implement a new value SHOULD be | content coding algorithms needed to implement a new value SHOULD be | |||
publicly available and adequate for independent implementation, and | publicly available and adequate for independent implementation, and | |||
conform to the purpose of content coding defined in this section. | conform to the purpose of content coding defined in this section. | |||
3.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 5.9) and Accept (Section 5.1) header fields in order to | |||
provide open and extensible data typing and type negotiation. | provide open and extensible data typing and type negotiation. | |||
media-type = type "/" subtype *( OWS ";" OWS parameter ) | media-type = type "/" subtype *( OWS ";" OWS parameter ) | |||
type = token | type = token | |||
subtype = token | subtype = token | |||
Parameters MAY follow the type/subtype in the form of attribute/value | Parameters MAY follow the type/subtype in the form of attribute/value | |||
pairs. | pairs. | |||
parameter = attribute "=" value | parameter = attribute "=" value | |||
skipping to change at page 9, line 36 | skipping to change at page 9, line 46 | |||
Note that some older HTTP applications do not recognize media type | Note that some older HTTP applications do not recognize media type | |||
parameters. When sending data to older HTTP applications, | parameters. When sending data to older HTTP applications, | |||
implementations SHOULD only use media type parameters when they are | implementations SHOULD only use media type parameters when they are | |||
required by that type/subtype definition. | required by that type/subtype definition. | |||
Media-type values are registered with the Internet Assigned Number | Media-type values are registered with the Internet Assigned Number | |||
Authority (IANA). The media type registration process is outlined in | Authority (IANA). The media type registration process is outlined in | |||
[RFC4288]. Use of non-registered media types is discouraged. | [RFC4288]. Use of non-registered media types is discouraged. | |||
3.3.1. Canonicalization and Text Defaults | 2.3.1. Canonicalization and Text Defaults | |||
Internet media types are registered with a canonical form. An | Internet media types are registered with a canonical form. An | |||
entity-body transferred via HTTP messages MUST be represented in the | entity-body transferred via HTTP messages MUST be represented in the | |||
appropriate canonical form prior to its transmission except for | appropriate canonical form prior to its transmission except for | |||
"text" types, as defined in the next paragraph. | "text" types, as defined in the next paragraph. | |||
When in canonical form, media subtypes of the "text" type use CRLF as | When in canonical form, media subtypes of the "text" type use CRLF as | |||
the text line break. HTTP relaxes this requirement and allows the | the text line break. HTTP relaxes this requirement and allows the | |||
transport of text media with plain CR or LF alone representing a line | transport of text media with plain CR or LF alone representing a line | |||
break when it is done consistently for an entire entity-body. HTTP | break when it is done consistently for an entire entity-body. HTTP | |||
skipping to change at page 10, line 13 | skipping to change at page 10, line 24 | |||
sequences are defined by that character set to represent the | sequences are defined by that character set 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 entity-body; a bare CR | line breaks applies only to text media in the entity-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 an entity-body is encoded with a content-coding, the underlying | If an entity-body 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 | The "charset" parameter is used with some media types to define the | |||
character set (Section 3.1) of the data. When no explicit charset | character set (Section 2.1) of the data. When no explicit charset | |||
parameter is provided by the sender, media subtypes of the "text" | 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 | type are defined to have a default charset value of "ISO-8859-1" when | |||
received via HTTP. Data in character sets other than "ISO-8859-1" or | received via HTTP. Data in character sets other than "ISO-8859-1" or | |||
its subsets MUST be labeled with an appropriate charset value. See | its subsets MUST be labeled with an appropriate charset value. See | |||
Section 3.1.1 for compatibility problems. | Section 2.1.1 for compatibility problems. | |||
3.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 entities within a single message-body. All multipart | one or more entities within a single message-body. All multipart | |||
types share a common syntax, as defined in Section 5.1.1 of | 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. | |||
Unlike in RFC 2046, the epilogue of any multipart message MUST be | Unlike in RFC 2046, the epilogue of any multipart message MUST be | |||
empty; HTTP applications MUST NOT transmit the epilogue (even if the | empty; HTTP applications MUST NOT transmit the epilogue (even if the | |||
original multipart contains an epilogue). These restrictions exist | original multipart contains an epilogue). These restrictions exist | |||
skipping to change at page 11, line 5 | skipping to change at page 11, line 15 | |||
In general, an HTTP user agent SHOULD follow the same or similar | In general, an HTTP user agent SHOULD follow the same or similar | |||
behavior as a MIME user agent would upon receipt of a multipart type. | behavior as a MIME user agent would upon receipt of a multipart type. | |||
If an application receives an unrecognized multipart subtype, the | If an application receives an unrecognized multipart subtype, the | |||
application MUST treat it as being equivalent to "multipart/mixed". | application MUST treat it as being equivalent to "multipart/mixed". | |||
Note: The "multipart/form-data" type has been specifically defined | Note: The "multipart/form-data" type has been specifically defined | |||
for carrying form data suitable for processing via the POST | for carrying form data suitable for processing via the POST | |||
request method, as described in [RFC2388]. | request method, as described in [RFC2388]. | |||
3.4. Quality Values | 2.4. Language Tags | |||
HTTP content negotiation (Section 5) uses short "floating point" | ||||
numbers to indicate the relative importance ("weight") of various | ||||
negotiable parameters. A weight is normalized to a real number in | ||||
the range 0 through 1, where 0 is the minimum and 1 the maximum | ||||
value. If a parameter has a quality value of 0, then content with | ||||
this parameter is `not acceptable' for the client. HTTP/1.1 | ||||
applications MUST NOT generate more than three digits after the | ||||
decimal point. User configuration of these values SHOULD also be | ||||
limited in this fashion. | ||||
qvalue = ( "0" [ "." 0*3DIGIT ] ) | ||||
/ ( "1" [ "." 0*3("0") ] ) | ||||
"Quality values" is a misnomer, since these values merely represent | ||||
relative degradation in desired quality. | ||||
3.5. Language Tags | ||||
A language tag identifies a natural language spoken, written, or | A language tag identifies a natural language spoken, written, or | |||
otherwise conveyed by human beings for communication of information | otherwise conveyed by human beings for communication of information | |||
to other human beings. Computer languages are explicitly excluded. | to other human beings. Computer languages are explicitly excluded. | |||
HTTP uses language tags within the Accept-Language and Content- | HTTP uses language tags within the Accept-Language and Content- | |||
Language fields. | Language fields. | |||
The syntax and registry of HTTP language tags is the same as that | The syntax and registry of HTTP language tags is the same as that | |||
defined by [RFC1766]. In summary, a language tag is composed of 1 or | defined by [RFC1766]. In summary, a language tag is composed of 1 or | |||
more parts: A primary language tag and a possibly empty series of | more parts: A primary language tag and a possibly empty series of | |||
skipping to change at page 12, line 5 | skipping to change at page 11, line 43 | |||
insensitive. The name space of language tags is administered by the | insensitive. The name space of language tags is administered by the | |||
IANA. Example tags include: | IANA. Example tags include: | |||
en, en-US, en-cockney, i-cherokee, x-pig-latin | en, en-US, en-cockney, i-cherokee, x-pig-latin | |||
where any two-letter primary-tag is an ISO-639 language abbreviation | where any two-letter primary-tag is an ISO-639 language abbreviation | |||
and any two-letter initial subtag is an ISO-3166 country code. (The | and any two-letter initial subtag is an ISO-3166 country code. (The | |||
last three tags above are not registered tags; all but the last are | last three tags above are not registered tags; all but the last are | |||
examples of tags which could be registered in future.) | examples of tags which could be registered in future.) | |||
4. Entity | 3. Entity | |||
Request and Response messages MAY transfer an entity if not otherwise | Request and Response messages MAY transfer an entity if not otherwise | |||
restricted by the request method or response status code. An entity | restricted by the request method or response status code. An entity | |||
consists of entity-header fields and an entity-body, although some | consists of entity-header fields and an entity-body, although some | |||
responses will only include the entity-headers. | responses will only include the entity-headers. | |||
In this section, both sender and recipient refer to either the client | In this section, both sender and recipient refer to either the client | |||
or the server, depending on who sends and who receives the entity. | or the server, depending on who sends and who receives the entity. | |||
4.1. Entity Header Fields | 3.1. Entity Header Fields | |||
Entity-header fields define metainformation about the entity-body or, | Entity-header fields define metainformation about the entity-body or, | |||
if no body is present, about the resource identified by the request. | if no body is present, about the resource identified by the request. | |||
entity-header = Content-Encoding ; Section 6.5 | entity-header = Content-Encoding ; Section 5.5 | |||
/ Content-Language ; Section 6.6 | / Content-Language ; Section 5.6 | |||
/ Content-Length ; [Part1], Section 8.2 | / Content-Length ; [Part1], Section 8.2 | |||
/ Content-Location ; Section 6.7 | / Content-Location ; Section 5.7 | |||
/ Content-MD5 ; Section 6.8 | / Content-MD5 ; Section 5.8 | |||
/ Content-Range ; [Part5], Section 6.2 | / Content-Range ; [Part5], Section 5.2 | |||
/ Content-Type ; Section 6.9 | / Content-Type ; Section 5.9 | |||
/ Expires ; [Part6], Section 16.3 | / Expires ; [Part6], Section 3.3 | |||
/ Last-Modified ; [Part4], Section 7.6 | / Last-Modified ; [Part4], Section 6.6 | |||
/ extension-header | / extension-header | |||
extension-header = message-header | extension-header = message-header | |||
The extension-header mechanism allows additional entity-header fields | The extension-header mechanism allows additional entity-header fields | |||
to be defined without changing the protocol, but these fields cannot | to be defined without changing the protocol, but these fields cannot | |||
be assumed to be recognizable by the recipient. Unrecognized header | be assumed to be recognizable by the recipient. Unrecognized header | |||
fields SHOULD be ignored by the recipient and MUST be forwarded by | fields SHOULD be ignored by the recipient and MUST be forwarded by | |||
transparent proxies. | transparent proxies. | |||
4.2. Entity Body | 3.2. Entity Body | |||
The entity-body (if any) sent with an HTTP request or response is in | The entity-body (if any) sent with an HTTP request or response is in | |||
a format and encoding defined by the entity-header fields. | a format and encoding defined by the entity-header fields. | |||
entity-body = *OCTET | entity-body = *OCTET | |||
An entity-body is only present in a message when a message-body is | An entity-body is only present in a message when a message-body is | |||
present, as described in Section 4.3 of [Part1]. The entity-body is | present, as described in Section 4.3 of [Part1]. The entity-body is | |||
obtained from the message-body by decoding any Transfer-Encoding that | obtained from the message-body by decoding any Transfer-Encoding that | |||
might have been applied to ensure safe and proper transfer of the | might have been applied to ensure safe and proper transfer of the | |||
message. | message. | |||
4.2.1. Type | 3.2.1. Type | |||
When an entity-body is included with a message, the data type of that | When an entity-body is included with a message, the data type of that | |||
body is determined via the header fields Content-Type and Content- | body is determined via the header fields Content-Type and Content- | |||
Encoding. These define a two-layer, ordered encoding model: | Encoding. These define a two-layer, ordered encoding model: | |||
entity-body := Content-Encoding( Content-Type( data ) ) | entity-body := Content-Encoding( Content-Type( data ) ) | |||
Content-Type specifies the media type of the underlying data. | Content-Type specifies the media type of the underlying data. | |||
Content-Encoding may be used to indicate any additional content | Content-Encoding may be used to indicate any additional content | |||
codings applied to the data, usually for the purpose of data | codings applied to the data, usually for the purpose of data | |||
compression, that are a property of the requested resource. There is | compression, that are a property of the requested resource. There is | |||
no default encoding. | no default encoding. | |||
Any HTTP/1.1 message containing an entity-body SHOULD include a | Any HTTP/1.1 message containing an entity-body SHOULD include a | |||
Content-Type header field defining the media type of that body. If | Content-Type header field defining the media type of that body. If | |||
and only if the media type is not given by a Content-Type field, the | and only if the media type is not given by a Content-Type field, the | |||
recipient MAY attempt to guess the media type via inspection of its | recipient MAY attempt to guess the media type via inspection of its | |||
content and/or the name extension(s) of the URI used to identify the | content and/or the name extension(s) of the URI used to identify the | |||
skipping to change at page 13, line 27 | skipping to change at page 13, line 18 | |||
no default encoding. | no default encoding. | |||
Any HTTP/1.1 message containing an entity-body SHOULD include a | Any HTTP/1.1 message containing an entity-body SHOULD include a | |||
Content-Type header field defining the media type of that body. If | Content-Type header field defining the media type of that body. If | |||
and only if the media type is not given by a Content-Type field, the | and only if the media type is not given by a Content-Type field, the | |||
recipient MAY attempt to guess the media type via inspection of its | recipient MAY attempt to guess the media type via inspection of its | |||
content and/or the name extension(s) of the URI used to identify the | content and/or the name extension(s) of the URI used to identify the | |||
resource. If the media type remains unknown, the recipient SHOULD | resource. If the media type remains unknown, the recipient SHOULD | |||
treat it as type "application/octet-stream". | treat it as type "application/octet-stream". | |||
4.2.2. Entity Length | 3.2.2. Entity Length | |||
The entity-length of a message is the length of the message-body | The entity-length of a message is the length of the message-body | |||
before any transfer-codings have been applied. Section 4.4 of | before any transfer-codings have been applied. Section 4.4 of | |||
[Part1] defines how the transfer-length of a message-body is | [Part1] defines how the transfer-length of a message-body is | |||
determined. | determined. | |||
5. Content Negotiation | 4. Content Negotiation | |||
Most HTTP responses include an entity which contains information for | Most HTTP responses include an entity which contains information for | |||
interpretation by a human user. Naturally, it is desirable to supply | interpretation by a human user. Naturally, it is desirable to supply | |||
the user with the "best available" entity corresponding to the | the user with the "best available" entity corresponding to the | |||
request. Unfortunately for servers and caches, not all users have | request. Unfortunately for servers and caches, not all users have | |||
the same preferences for what is "best," and not all user agents are | the same preferences for what is "best," and not all user agents are | |||
equally capable of rendering all entity types. For that reason, HTTP | equally capable of rendering all entity types. For that reason, HTTP | |||
has provisions for several mechanisms for "content negotiation" -- | has provisions for several mechanisms for "content negotiation" -- | |||
the process of selecting the best representation for a given response | the process of selecting the best representation for a given response | |||
when there are multiple representations available. | when there are multiple representations available. | |||
skipping to change at page 14, line 14 | skipping to change at page 14, line 5 | |||
including error responses. | including error responses. | |||
There are two kinds of content negotiation which are possible in | There are two kinds of content negotiation which are possible in | |||
HTTP: server-driven and agent-driven negotiation. These two kinds of | HTTP: server-driven and agent-driven negotiation. These two kinds of | |||
negotiation are orthogonal and thus may be used separately or in | negotiation are orthogonal and thus may be used separately or in | |||
combination. One method of combination, referred to as transparent | combination. One method of combination, referred to as transparent | |||
negotiation, occurs when a cache uses the agent-driven negotiation | negotiation, occurs when a cache uses the agent-driven negotiation | |||
information provided by the origin server in order to provide server- | information provided by the origin server in order to provide server- | |||
driven negotiation for subsequent requests. | driven negotiation for subsequent requests. | |||
5.1. Server-driven Negotiation | 4.1. Server-driven Negotiation | |||
If the selection of the best representation for a response is made by | If the selection of the best representation for a response is made by | |||
an algorithm located at the server, it is called server-driven | an algorithm located at the server, it is called server-driven | |||
negotiation. Selection is based on the available representations of | negotiation. Selection is based on the available representations of | |||
the response (the dimensions over which it can vary; e.g. language, | the response (the dimensions over which it can vary; e.g. language, | |||
content-coding, etc.) and the contents of particular header fields in | content-coding, etc.) and the contents of particular header fields in | |||
the request message or on other information pertaining to the request | the request message or on other information pertaining to the request | |||
(such as the network address of the client). | (such as the network address of the client). | |||
Server-driven negotiation is advantageous when the algorithm for | Server-driven negotiation is advantageous when the algorithm for | |||
skipping to change at page 15, line 7 | skipping to change at page 14, line 46 | |||
violation of the user's privacy. | violation of the user's privacy. | |||
3. It complicates the implementation of an origin server and the | 3. It complicates the implementation of an origin server and the | |||
algorithms for generating responses to a request. | algorithms for generating responses to a request. | |||
4. It may limit a public cache's ability to use the same response | 4. It may limit a public cache's ability to use the same response | |||
for multiple user's requests. | for multiple user's requests. | |||
HTTP/1.1 includes the following request-header fields for enabling | HTTP/1.1 includes the following request-header fields for enabling | |||
server-driven negotiation through description of user agent | server-driven negotiation through description of user agent | |||
capabilities and user preferences: Accept (Section 6.1), Accept- | capabilities and user preferences: Accept (Section 5.1), Accept- | |||
Charset (Section 6.2), Accept-Encoding (Section 6.3), Accept-Language | Charset (Section 5.2), Accept-Encoding (Section 5.3), Accept-Language | |||
(Section 6.4), and User-Agent (Section 10.9 of [Part2]). However, an | (Section 5.4), and User-Agent (Section 9.9 of [Part2]). However, an | |||
origin server is not limited to these dimensions and MAY vary the | origin server is not limited to these dimensions and MAY vary the | |||
response based on any aspect of the request, including information | response based on any aspect of the request, including information | |||
outside the request-header fields or within extension header fields | outside the request-header fields or within extension header fields | |||
not defined by this specification. | not defined by this specification. | |||
The Vary header field (Section 16.5 of [Part6]) can be used to | The Vary header field (Section 3.5 of [Part6]) can be used to express | |||
express the parameters the server uses to select a representation | the parameters the server uses to select a representation that is | |||
that is subject to server-driven negotiation. | subject to server-driven negotiation. | |||
5.2. Agent-driven Negotiation | 4.2. Agent-driven Negotiation | |||
With agent-driven negotiation, selection of the best representation | With agent-driven negotiation, selection of the best representation | |||
for a response is performed by the user agent after receiving an | for a response is performed by the user agent after receiving an | |||
initial response from the origin server. Selection is based on a | initial response from the origin server. Selection is based on a | |||
list of the available representations of the response included within | list of the available representations of the response included within | |||
the header fields or entity-body of the initial response, with each | the header fields or entity-body of the initial response, with each | |||
representation identified by its own URI. Selection from among the | representation identified by its own URI. Selection from among the | |||
representations may be performed automatically (if the user agent is | representations may be performed automatically (if the user agent is | |||
capable of doing so) or manually by the user selecting from a | capable of doing so) or manually by the user selecting from a | |||
generated (possibly hypertext) menu. | generated (possibly hypertext) menu. | |||
skipping to change at page 16, line 5 | skipping to change at page 15, line 40 | |||
this specification does not define any mechanism for supporting | this specification does not define any mechanism for supporting | |||
automatic selection, though it also does not prevent any such | automatic selection, though it also does not prevent any such | |||
mechanism from being developed as an extension and used within | mechanism from being developed as an extension and used within | |||
HTTP/1.1. | HTTP/1.1. | |||
HTTP/1.1 defines the 300 (Multiple Choices) and 406 (Not Acceptable) | HTTP/1.1 defines the 300 (Multiple Choices) and 406 (Not Acceptable) | |||
status codes for enabling agent-driven negotiation when the server is | status codes for enabling agent-driven negotiation when the server is | |||
unwilling or unable to provide a varying response using server-driven | unwilling or unable to provide a varying response using server-driven | |||
negotiation. | negotiation. | |||
5.3. Transparent Negotiation | 4.3. Transparent Negotiation | |||
Transparent negotiation is a combination of both server-driven and | Transparent negotiation is a combination of both server-driven and | |||
agent-driven negotiation. When a cache is supplied with a form of | agent-driven negotiation. When a cache is supplied with a form of | |||
the list of available representations of the response (as in agent- | the list of available representations of the response (as in agent- | |||
driven negotiation) and the dimensions of variance are completely | driven negotiation) and the dimensions of variance are completely | |||
understood by the cache, then the cache becomes capable of performing | understood by the cache, then the cache becomes capable of performing | |||
server-driven negotiation on behalf of the origin server for | server-driven negotiation on behalf of the origin server for | |||
subsequent requests on that resource. | subsequent requests on that resource. | |||
Transparent negotiation has the advantage of distributing the | Transparent negotiation has the advantage of distributing the | |||
negotiation work that would otherwise be required of the origin | negotiation work that would otherwise be required of the origin | |||
server and also removing the second request delay of agent-driven | server and also removing the second request delay of agent-driven | |||
negotiation when the cache is able to correctly guess the right | negotiation when the cache is able to correctly guess the right | |||
response. | response. | |||
This specification does not define any mechanism for transparent | This specification does not define any mechanism for transparent | |||
negotiation, though it also does not prevent any such mechanism from | negotiation, though it also does not prevent any such mechanism from | |||
being developed as an extension that could be used within HTTP/1.1. | being developed as an extension that could be used within HTTP/1.1. | |||
6. Header Field Definitions | 5. Header Field Definitions | |||
This section defines the syntax and semantics of HTTP/1.1 header | This section defines the syntax and semantics of HTTP/1.1 header | |||
fields related to the payload of messages. | fields related to the payload of messages. | |||
For entity-header fields, both sender and recipient refer to either | For entity-header fields, both sender and recipient refer to either | |||
the client or the server, depending on who sends and who receives the | the client or the server, depending on who sends and who receives the | |||
entity. | entity. | |||
6.1. Accept | 5.1. Accept | |||
The request-header field "Accept" can be used to specify certain | The request-header field "Accept" can be used to specify certain | |||
media types which are acceptable for the response. Accept headers | media types which are acceptable for the response. Accept headers | |||
can be used to indicate that the request is specifically limited to a | can 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 = "Accept" ":" OWS Accept-v | |||
Accept-v = #( media-range [ accept-params ] ) | Accept-v = #( media-range [ accept-params ] ) | |||
skipping to change at page 17, line 14 | skipping to change at page 16, line 49 | |||
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 3.4). The | media-range, using the qvalue scale from 0 to 1 (Section 3.5 of | |||
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". | |||
skipping to change at page 18, line 4 | skipping to change at page 17, line 40 | |||
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 entity, and if that does not exist, send the text/plain | text/x-dvi entity, and if that does not exist, send the text/plain | |||
entity." | entity." | |||
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/html, text/html;level=1, */* | |||
have the following precedence: | have the following precedence: | |||
1) text/html;level=1 | 1. text/html;level=1 | |||
2) text/html | ||||
3) text/* | ||||
4) */* | ||||
2. text/html | ||||
3. text/* | ||||
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, | |||
text/html;level=2;q=0.4, */*;q=0.5 | text/html;level=2;q=0.4, */*;q=0.5 | |||
would cause the following values to be associated: | would cause the following values to be associated: | |||
text/html;level=1 = 1 | +-------------------+---------------+ | |||
text/html = 0.7 | | Media Type | Quality Value | | |||
text/plain = 0.3 | +-------------------+---------------+ | |||
image/jpeg = 0.5 | | text/html;level=1 | 1 | | |||
text/html;level=2 = 0.4 | | text/html | 0.7 | | |||
text/html;level=3 = 0.7 | | text/plain | 0.3 | | |||
| image/jpeg | 0.5 | | ||||
| text/html;level=2 | 0.4 | | ||||
| text/html;level=3 | 0.7 | | ||||
+-------------------+---------------+ | ||||
Note: A user agent might be provided with a default set of quality | Note: A user agent might be provided with a default set of quality | |||
values for certain media ranges. However, unless the user agent is a | values for certain media ranges. However, unless the user agent is a | |||
closed system which cannot interact with other rendering agents, this | closed system which cannot interact with other rendering agents, this | |||
default set ought to be configurable by the user. | default set ought to be configurable by the user. | |||
6.2. Accept-Charset | 5.2. Accept-Charset | |||
The request-header field "Accept-Charset" can be used to indicate | The request-header field "Accept-Charset" can be used to indicate | |||
what character sets are acceptable for the response. This field | what character sets are acceptable for the response. This field | |||
allows clients capable of understanding more comprehensive or | allows clients capable of understanding more comprehensive or | |||
special-purpose character sets to signal that capability to a server | special-purpose character sets to signal that capability to a server | |||
which is capable of representing documents in those character sets. | which is capable of representing documents in those character sets. | |||
Accept-Charset = "Accept-Charset" ":" OWS | Accept-Charset = "Accept-Charset" ":" OWS | |||
Accept-Charset-v | Accept-Charset-v | |||
Accept-Charset-v = 1#( ( charset / "*" ) | Accept-Charset-v = 1#( ( charset / "*" ) | |||
[ OWS ";" OWS "q=" qvalue ] ) | [ OWS ";" OWS "q=" qvalue ] ) | |||
Character set values are described in Section 3.1. Each charset MAY | Character set values are described in Section 2.1. Each charset MAY | |||
be given an associated quality value which represents the user's | be given an associated quality value which represents the user's | |||
preference for that charset. The default value is q=1. An example | preference for that charset. The default value is q=1. An example | |||
is | is | |||
Accept-Charset: iso-8859-5, unicode-1-1;q=0.8 | Accept-Charset: iso-8859-5, unicode-1-1;q=0.8 | |||
The special value "*", if present in the Accept-Charset field, | The special value "*", if present in the Accept-Charset field, | |||
matches every character set (including ISO-8859-1) which is not | matches every character set (including ISO-8859-1) which is not | |||
mentioned elsewhere in the Accept-Charset field. If no "*" is | mentioned elsewhere in the Accept-Charset field. If no "*" is | |||
present in an Accept-Charset field, then all character sets not | present in an Accept-Charset field, then all character sets not | |||
explicitly mentioned get a quality value of 0, except for ISO-8859-1, | explicitly mentioned get a quality value of 0, except for ISO-8859-1, | |||
which gets a quality value of 1 if not explicitly mentioned. | which gets a quality value of 1 if not explicitly mentioned. | |||
If no Accept-Charset header is present, the default is that any | If no Accept-Charset header is present, the default is that any | |||
skipping to change at page 19, line 20 | skipping to change at page 19, line 15 | |||
explicitly mentioned get a quality value of 0, except for ISO-8859-1, | explicitly mentioned get a quality value of 0, except for ISO-8859-1, | |||
which gets a quality value of 1 if not explicitly mentioned. | which gets a quality value of 1 if not explicitly mentioned. | |||
If no Accept-Charset header is present, the default is that any | If no Accept-Charset header is present, the default is that any | |||
character set is acceptable. If an Accept-Charset header is present, | character set is acceptable. If an Accept-Charset header is present, | |||
and if the server cannot send a response which is acceptable | and if the server cannot send a response which is acceptable | |||
according to the Accept-Charset header, then the server SHOULD send | according to the Accept-Charset header, then the server SHOULD send | |||
an error response with the 406 (Not Acceptable) status code, though | an error response with the 406 (Not Acceptable) status code, though | |||
the sending of an unacceptable response is also allowed. | the sending of an unacceptable response is also allowed. | |||
6.3. Accept-Encoding | 5.3. Accept-Encoding | |||
The request-header field "Accept-Encoding" is similar to Accept, but | The request-header field "Accept-Encoding" is similar to Accept, but | |||
restricts the content-codings (Section 3.2) that are acceptable in | restricts the content-codings (Section 2.2) that are acceptable in | |||
the response. | the response. | |||
Accept-Encoding = "Accept-Encoding" ":" OWS | Accept-Encoding = "Accept-Encoding" ":" OWS | |||
Accept-Encoding-v | Accept-Encoding-v | |||
Accept-Encoding-v = | Accept-Encoding-v = | |||
#( codings [ OWS ";" OWS "q=" qvalue ] ) | #( codings [ OWS ";" OWS "q=" qvalue ] ) | |||
codings = ( content-coding / "*" ) | codings = ( content-coding / "*" ) | |||
Each codings value MAY be given an associated quality value which | Each codings value MAY be given an associated quality value which | |||
represents the preference for that encoding. The default value is | represents the preference for that encoding. The default value is | |||
skipping to change at page 19, line 49 | skipping to change at page 19, line 44 | |||
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 is acceptable, according to | |||
an Accept-Encoding field, using these rules: | an Accept-Encoding field, using these rules: | |||
1. If the content-coding is one of the content-codings listed in the | 1. If the content-coding is one of the content-codings listed in the | |||
Accept-Encoding field, then it is acceptable, unless it is | Accept-Encoding field, then it is acceptable, unless it is | |||
accompanied by a qvalue of 0. (As defined in Section 3.4, a | accompanied by a qvalue of 0. (As defined in Section 3.5 of | |||
qvalue of 0 means "not acceptable.") | [Part1], a qvalue of 0 means "not acceptable.") | |||
2. The special "*" symbol in an Accept-Encoding field matches any | 2. 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 | 3. If multiple content-codings are acceptable, then the acceptable | |||
content-coding with the highest non-zero qvalue is preferred. | content-coding with the highest non-zero qvalue is preferred. | |||
4. The "identity" content-coding is always acceptable, unless | 4. The "identity" content-coding is always acceptable, unless | |||
specifically refused because the Accept-Encoding field includes | specifically refused because the Accept-Encoding field includes | |||
"identity;q=0", or because the field includes "*;q=0" and does | "identity;q=0", or because the field includes "*;q=0" and does | |||
skipping to change at page 20, line 42 | skipping to change at page 20, line 39 | |||
codings commonly understood by HTTP/1.0 clients (i.e., "gzip" and | codings commonly understood by HTTP/1.0 clients (i.e., "gzip" and | |||
"compress") are preferred; some older clients improperly display | "compress") are preferred; some older clients improperly display | |||
messages sent with other content-codings. The server might also | messages sent with other content-codings. The server might also | |||
make this decision based on information about the particular user- | make this decision based on information about the particular user- | |||
agent or client. | agent or client. | |||
Note: Most HTTP/1.0 applications do not recognize or obey qvalues | Note: Most HTTP/1.0 applications do not recognize or obey qvalues | |||
associated with content-codings. This means that qvalues will not | associated with content-codings. This means that qvalues will not | |||
work and are not permitted with x-gzip or x-compress. | work and are not permitted with x-gzip or x-compress. | |||
6.4. Accept-Language | 5.4. Accept-Language | |||
The request-header field "Accept-Language" is similar to Accept, but | The request-header field "Accept-Language" is similar to Accept, but | |||
restricts the set of natural languages that are preferred as a | restricts the set of natural languages that are preferred as a | |||
response to the request. Language tags are defined in Section 3.5. | response to the request. Language tags are defined in Section 2.4. | |||
Accept-Language = "Accept-Language" ":" OWS | Accept-Language = "Accept-Language" ":" OWS | |||
Accept-Language-v | Accept-Language-v | |||
Accept-Language-v = | Accept-Language-v = | |||
1#( language-range [ OWS ";" OWS "q=" qvalue ] ) | 1#( language-range [ OWS ";" OWS "q=" qvalue ] ) | |||
language-range = | language-range = | |||
<language-range, defined in [RFC4647], Section 2.1> | <language-range, defined in [RFC4647], Section 2.1> | |||
Each language-range can be given an associated quality value which | Each language-range can be given an associated quality value which | |||
represents an estimate of the user's preference for the languages | represents an estimate of the user's preference for the languages | |||
skipping to change at page 22, line 4 | skipping to change at page 21, line 44 | |||
the field that matches the language-tag. If no language-range in the | the field that matches the language-tag. If no language-range in the | |||
field matches the tag, the language quality factor assigned is 0. If | field matches the tag, the language quality factor assigned is 0. If | |||
no Accept-Language header is present in the request, the server | no Accept-Language header is present in the request, the server | |||
SHOULD assume that all languages are equally acceptable. If an | SHOULD assume that all languages are equally acceptable. If an | |||
Accept-Language header is present, then all languages which are | Accept-Language header is present, then all languages which are | |||
assigned a quality factor greater than 0 are acceptable. | assigned a quality factor greater than 0 are acceptable. | |||
It might be contrary to the privacy expectations of the user to send | It might be contrary to the privacy expectations of the user to send | |||
an Accept-Language header with the complete linguistic preferences of | an Accept-Language header with the complete linguistic preferences of | |||
the user in every request. For a discussion of this issue, see | the user in every request. For a discussion of this issue, see | |||
Section 8.1. | Section 7.1. | |||
As intelligibility is highly dependent on the individual user, it is | As intelligibility is highly dependent on the individual user, it is | |||
recommended that client applications make the choice of linguistic | recommended that client applications make the choice of linguistic | |||
preference available to the user. If the choice is not made | preference available to the user. If the choice is not made | |||
available, then the Accept-Language header field MUST NOT be given in | available, then the Accept-Language header field MUST NOT be given in | |||
the request. | the request. | |||
Note: When making the choice of linguistic preference available to | Note: When making the choice of linguistic preference available to | |||
the user, we remind implementors of the fact that users are not | the user, we remind implementors of the fact that users are not | |||
familiar with the details of language matching as described above, | familiar with the details of language matching as described above, | |||
and should provide appropriate guidance. As an example, users | and should provide appropriate guidance. As an example, users | |||
might assume that on selecting "en-gb", they will be served any | might assume that on selecting "en-gb", they will be served any | |||
kind of English document if British English is not available. A | 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 | user agent might suggest in such a case to add "en" to get the | |||
best matching behavior. | best matching behavior. | |||
6.5. Content-Encoding | 5.5. Content-Encoding | |||
The entity-header field "Content-Encoding" is used as a modifier to | The entity-header field "Content-Encoding" is used as a modifier to | |||
the media-type. When present, its value indicates what additional | the media-type. When present, its value indicates what additional | |||
content codings have been applied to the entity-body, and thus what | content codings have been applied to the entity-body, and thus what | |||
decoding mechanisms must be applied in order to obtain the media-type | decoding 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 document to be compressed without losing | primarily used to allow a document to be compressed without losing | |||
the identity of its underlying media type. | the identity of its underlying media type. | |||
Content-Encoding = "Content-Encoding" ":" OWS Content-Encoding-v | Content-Encoding = "Content-Encoding" ":" OWS Content-Encoding-v | |||
Content-Encoding-v = 1#content-coding | Content-Encoding-v = 1#content-coding | |||
Content codings are defined in Section 3.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 entity identified by | The content-coding is a characteristic of the entity identified by | |||
the Request-URI. Typically, the entity-body is stored with this | the request-target. Typically, the entity-body is stored with this | |||
encoding and is only decoded before rendering or analogous usage. | encoding and is only decoded before rendering or analogous usage. | |||
However, a non-transparent proxy MAY modify the content-coding if the | However, a non-transparent proxy MAY modify the content-coding if the | |||
new coding is known to be acceptable to the recipient, unless the | new coding is known to be acceptable to the recipient, unless the | |||
"no-transform" cache-control directive is present in the message. | "no-transform" cache-control directive is present in the message. | |||
If the content-coding of an entity is not "identity", then the | If the content-coding of an entity is not "identity", then the | |||
response MUST include a Content-Encoding entity-header (Section 6.5) | response MUST include a Content-Encoding entity-header (Section 5.5) | |||
that lists the non-identity content-coding(s) used. | that lists the non-identity content-coding(s) used. | |||
If the content-coding of an entity in a request message is not | If the content-coding of an entity in a request message is not | |||
acceptable to the origin server, the server SHOULD respond with a | acceptable to the origin server, the server SHOULD respond with a | |||
status code of 415 (Unsupported Media Type). | status code of 415 (Unsupported Media Type). | |||
If multiple encodings have been applied to an entity, the content | If multiple encodings have been applied to an entity, the content | |||
codings MUST be listed in the order in which they were applied. | codings MUST be listed in the order in which they were applied. | |||
Additional information about the encoding parameters MAY be provided | Additional information about the encoding parameters MAY be provided | |||
by other entity-header fields not defined by this specification. | by other entity-header fields not defined by this specification. | |||
6.6. Content-Language | 5.6. Content-Language | |||
The entity-header field "Content-Language" describes the natural | The entity-header field "Content-Language" describes the natural | |||
language(s) of the intended audience for the enclosed entity. Note | language(s) of the intended audience for the enclosed entity. Note | |||
that this might not be equivalent to all the languages used within | that this might not be equivalent to all the languages used within | |||
the entity-body. | the entity-body. | |||
Content-Language = "Content-Language" ":" OWS Content-Language-v | Content-Language = "Content-Language" ":" OWS Content-Language-v | |||
Content-Language-v = 1#language-tag | Content-Language-v = 1#language-tag | |||
Language tags are defined in Section 3.5. 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 | |||
entities according to the user's own preferred language. Thus, if | entities according to the user's own preferred language. Thus, if | |||
the body content is intended only for a Danish-literate audience, the | the body content is intended only for a Danish-literate audience, the | |||
appropriate field is | 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 | |||
is intended for all language audiences. This might mean that the | is intended for all language audiences. This might mean that the | |||
sender does not consider it to be specific to any natural language, | sender does not consider it to be specific to any natural language, | |||
skipping to change at page 24, line 5 | skipping to change at page 23, line 45 | |||
However, just because multiple languages are present within an entity | However, just because multiple languages are present within an entity | |||
does not mean that it is intended for multiple linguistic audiences. | does not mean that it is intended for multiple linguistic audiences. | |||
An example would be a beginner's language primer, such as "A First | An example would be a beginner's language primer, such as "A First | |||
Lesson in Latin," which is clearly intended to be used by an English- | Lesson in Latin," which is clearly intended to be used by an English- | |||
literate audience. In this case, the Content-Language would properly | literate audience. In this case, the Content-Language would properly | |||
only include "en". | only include "en". | |||
Content-Language MAY be applied to any media type -- it is not | Content-Language MAY be applied to any media type -- it is not | |||
limited to textual documents. | limited to textual documents. | |||
6.7. Content-Location | 5.7. Content-Location | |||
The entity-header field "Content-Location" MAY be used to supply the | The entity-header field "Content-Location" MAY be used to supply the | |||
resource location for the entity enclosed in the message when that | resource location for the entity enclosed in the message when that | |||
entity is accessible from a location separate from the requested | entity is accessible from a location separate from the requested | |||
resource's URI. A server SHOULD provide a Content-Location for the | resource's URI. A server SHOULD provide a Content-Location for the | |||
variant corresponding to the response entity; especially in the case | variant corresponding to the response entity; especially in the case | |||
where a resource has multiple entities associated with it, and those | where a resource has multiple entities associated with it, and those | |||
entities actually have separate locations by which they might be | entities actually have separate locations by which they might be | |||
individually accessed, the server SHOULD provide a Content-Location | individually accessed, the server SHOULD provide a Content-Location | |||
for the particular variant which is returned. | for the particular variant which is returned. | |||
Content-Location = "Content-Location" ":" OWS | Content-Location = "Content-Location" ":" OWS | |||
Content-Location-v | Content-Location-v | |||
Content-Location-v = | Content-Location-v = | |||
absolute-URI / relativeURI | absolute-URI / partial-URI | |||
The value of Content-Location also defines the base URI for the | The value of Content-Location also defines the base URI for the | |||
entity. | entity. | |||
The Content-Location value is not a replacement for the original | The Content-Location value is not a replacement for the original | |||
requested URI; it is only a statement of the location of the resource | requested URI; it is only a statement of the location of the resource | |||
corresponding to this particular entity at the time of the request. | corresponding to this particular entity at the time of the request. | |||
Future requests MAY specify the Content-Location URI as the request- | Future requests MAY specify the Content-Location URI as the request- | |||
URI if the desire is to identify the source of that particular | target if the desire is to identify the source of that particular | |||
entity. | entity. | |||
A cache cannot assume that an entity with a Content-Location | A cache cannot assume that an entity 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. However, the Content- | later requests on that Content-Location URI. However, the Content- | |||
Location can be used to differentiate between multiple entities | Location can be used to differentiate between multiple entities | |||
retrieved from a single requested resource, as described in Section 8 | retrieved from a single requested resource, as described in Section | |||
of [Part6]. | 2.6 of [Part6]. | |||
If the Content-Location is a relative URI, the relative URI is | If the Content-Location is a relative URI, the relative URI is | |||
interpreted relative to the Request-URI. | interpreted relative to the request-target. | |||
The meaning of the Content-Location header in PUT or POST requests is | The meaning of the Content-Location header in PUT or POST requests is | |||
undefined; servers are free to ignore it in those cases. | undefined; servers are free to ignore it in those cases. | |||
6.8. Content-MD5 | 5.8. Content-MD5 | |||
The entity-header field "Content-MD5", as defined in [RFC1864], is an | The entity-header field "Content-MD5", as defined in [RFC1864], is an | |||
MD5 digest of the entity-body for the purpose of providing an end-to- | MD5 digest of the entity-body for the purpose of providing an end-to- | |||
end message integrity check (MIC) of the entity-body. (Note: a MIC | end message integrity check (MIC) of the entity-body. (Note: a MIC | |||
is good for detecting accidental modification of the entity-body in | is good for detecting accidental modification of the entity-body in | |||
transit, but is not proof against malicious attacks.) | transit, but is not proof against malicious attacks.) | |||
Content-MD5 = "Content-MD5" ":" OWS Content-MD5-v | Content-MD5 = "Content-MD5" ":" OWS Content-MD5-v | |||
Content-MD5-v = <base64 of 128 bit MD5 digest as per [RFC1864]> | Content-MD5-v = <base64 of 128 bit MD5 digest as per [RFC1864]> | |||
The Content-MD5 header field MAY be generated by an origin server or | The Content-MD5 header field MAY be generated by an origin server or | |||
client to function as an integrity check of the entity-body. Only | client to function as an integrity check of the entity-body. Only | |||
origin servers or clients MAY generate the Content-MD5 header field; | origin servers or clients MAY generate the Content-MD5 header field; | |||
proxies and gateways MUST NOT generate it, as this would defeat its | proxies and gateways MUST NOT generate it, as this would defeat its | |||
value as an end-to-end integrity check. Any recipient of the entity- | value as an end-to-end integrity check. Any recipient of the entity- | |||
body, including gateways and proxies, MAY check that the digest value | body, including gateways and proxies, MAY check that the digest value | |||
in this header field matches that of the entity-body as received. | in this header field matches that of the entity-body as received. | |||
skipping to change at page 26, line 9 | skipping to change at page 26, line 5 | |||
in which the application of Content-MD5 to HTTP entity-bodies | in which the application of Content-MD5 to HTTP entity-bodies | |||
differs from its application to MIME entity-bodies. One is that | differs from its application to MIME entity-bodies. One is that | |||
HTTP, unlike MIME, does not use Content-Transfer-Encoding, and | HTTP, unlike MIME, does not use Content-Transfer-Encoding, and | |||
does use Transfer-Encoding and Content-Encoding. Another is that | does use Transfer-Encoding and Content-Encoding. Another is that | |||
HTTP more frequently uses binary content types than MIME, so it is | HTTP more frequently uses binary content types than MIME, so it is | |||
worth noting that, in such cases, the byte order used to compute | worth noting that, in such cases, the byte order used to compute | |||
the digest is the transmission byte order defined for the type. | the digest is the transmission byte order defined for the type. | |||
Lastly, HTTP allows transmission of text types with any of several | Lastly, HTTP allows transmission of text types with any of several | |||
line break conventions and not just the canonical form using CRLF. | line break conventions and not just the canonical form using CRLF. | |||
6.9. Content-Type | 5.9. Content-Type | |||
The entity-header field "Content-Type" indicates the media type of | The entity-header field "Content-Type" indicates the media type of | |||
the entity-body sent to the recipient or, in the case of the HEAD | the entity-body sent to the recipient or, in the case of the HEAD | |||
method, the media type that would have been sent had the request been | method, the media type that would have been sent had the request been | |||
a GET. | a GET. | |||
Content-Type = "Content-Type" ":" OWS Content-Type-v | Content-Type = "Content-Type" ":" OWS Content-Type-v | |||
Content-Type-v = media-type | Content-Type-v = media-type | |||
Media types are defined in Section 3.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 methods for identifying the media type of an | Further discussion of methods for identifying the media type of an | |||
entity is provided in Section 4.2.1. | entity is provided in Section 3.2.1. | |||
7. IANA Considerations | 6. IANA Considerations | |||
7.1. Message Header Registration | 6.1. Message Header Registration | |||
The Message Header Registry located at <http://www.iana.org/ | The Message Header Registry located at <http://www.iana.org/ | |||
assignments/message-headers/message-header-index.html> should be | assignments/message-headers/message-header-index.html> should be | |||
updated with the permanent registrations below (see [RFC3864]): | updated with the permanent registrations below (see [RFC3864]): | |||
+---------------------+----------+----------+--------------+ | +---------------------+----------+----------+--------------+ | |||
| Header Field Name | Protocol | Status | Reference | | | Header Field Name | Protocol | Status | Reference | | |||
+---------------------+----------+----------+--------------+ | +---------------------+----------+----------+--------------+ | |||
| Accept | http | standard | Section 6.1 | | | Accept | http | standard | Section 5.1 | | |||
| Accept-Charset | http | standard | Section 6.2 | | | Accept-Charset | http | standard | Section 5.2 | | |||
| Accept-Encoding | http | standard | Section 6.3 | | | Accept-Encoding | http | standard | Section 5.3 | | |||
| Accept-Language | http | standard | Section 6.4 | | | Accept-Language | http | standard | Section 5.4 | | |||
| Content-Disposition | http | | Appendix B.1 | | | Content-Disposition | http | | Appendix B.1 | | |||
| Content-Encoding | http | standard | Section 6.5 | | | Content-Encoding | http | standard | Section 5.5 | | |||
| Content-Language | http | standard | Section 6.6 | | | Content-Language | http | standard | Section 5.6 | | |||
| Content-Location | http | standard | Section 6.7 | | | Content-Location | http | standard | Section 5.7 | | |||
| Content-MD5 | http | standard | Section 6.8 | | | Content-MD5 | http | standard | Section 5.8 | | |||
| Content-Type | http | standard | Section 6.9 | | | Content-Type | http | standard | Section 5.9 | | |||
| MIME-Version | http | | Appendix A.1 | | | MIME-Version | http | | 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". | |||
8. Security Considerations | 7. Security Considerations | |||
This section is meant to inform application developers, information | This section is meant to inform application developers, information | |||
providers, and users of the security limitations in HTTP/1.1 as | providers, and users of the security limitations in HTTP/1.1 as | |||
described by this document. The discussion does not include | described by this document. The discussion does not include | |||
definitive solutions to the problems revealed, though it does make | definitive solutions to the problems revealed, though it does make | |||
some suggestions for reducing security risks. | some suggestions for reducing security risks. | |||
8.1. Privacy Issues Connected to Accept Headers | 7.1. Privacy Issues Connected to Accept Headers | |||
Accept request-headers can reveal information about the user to all | Accept request-headers can reveal information about the user to all | |||
servers which are accessed. The Accept-Language header in particular | servers which are accessed. The Accept-Language header in particular | |||
can reveal information the user would consider to be of a private | can reveal information the user would consider to be of a private | |||
nature, because the understanding of particular languages is often | nature, because the understanding of particular languages is often | |||
strongly correlated to the membership of a particular ethnic group. | strongly correlated to the membership of a particular ethnic group. | |||
User agents which offer the option to configure the contents of an | User agents which offer the option to configure the contents of an | |||
Accept-Language header to be sent in every request are strongly | Accept-Language header to be sent in every request are strongly | |||
encouraged to let the configuration process include a message which | encouraged to let the configuration process include a message which | |||
makes the user aware of the loss of privacy involved. | makes the user aware of the loss of privacy involved. | |||
skipping to change at page 28, line 5 | skipping to change at page 27, line 48 | |||
many users not behind a proxy, the network address of the host | many users not behind a proxy, the network address of the host | |||
running the user agent will also serve as a long-lived user | running the user agent will also serve as a long-lived user | |||
identifier. In environments where proxies are used to enhance | identifier. In environments where proxies are used to enhance | |||
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 headers in relayed requests. | measure, proxies could filter the accept headers in relayed requests. | |||
General purpose user agents which provide a high degree of header | General purpose user agents which provide a high degree of header | |||
configurability SHOULD warn users about the loss of privacy which can | configurability SHOULD warn users about the loss of privacy which can | |||
be involved. | be involved. | |||
8.2. Content-Disposition Issues | 7.2. Content-Disposition Issues | |||
[RFC2183], from which the often implemented Content-Disposition (see | [RFC2183], from which the often implemented Content-Disposition (see | |||
Appendix B.1) header in HTTP is derived, has a number of very serious | Appendix B.1) header in HTTP is derived, has a number of very serious | |||
security considerations. Content-Disposition is not part of the HTTP | security considerations. Content-Disposition is not part of the HTTP | |||
standard, but since it is widely implemented, we are documenting its | standard, but since it is widely implemented, we are documenting its | |||
use and risks for implementors. See Section 5 of [RFC2183] for | use and risks for implementors. See Section 5 of [RFC2183] for | |||
details. | details. | |||
9. Acknowledgments | 8. Acknowledgments | |||
10. References | 9. References | |||
10.1. Normative References | 9.1. Normative References | |||
[ISO-8859-1] | [ISO-8859-1] | |||
International Organization for Standardization, | International Organization for Standardization, | |||
"Information technology -- 8-bit single-byte coded graphic | "Information technology -- 8-bit single-byte coded graphic | |||
character sets -- Part 1: Latin alphabet No. 1", ISO/ | character sets -- Part 1: Latin alphabet No. 1", ISO/ | |||
IEC 8859-1:1998, 1998. | IEC 8859-1:1998, 1998. | |||
[Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | |||
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., 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-05 | and Message Parsing", draft-ietf-httpbis-p1-messaging-06 | |||
(work in progress), November 2008. | (work in progress), March 2009. | |||
[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-05 (work in | Semantics", draft-ietf-httpbis-p2-semantics-06 (work in | |||
progress), November 2008. | progress), March 2009. | |||
[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-05 (work in | Requests", draft-ietf-httpbis-p4-conditional-06 (work in | |||
progress), November 2008. | progress), March 2009. | |||
[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-05 (work | Partial Responses", draft-ietf-httpbis-p5-range-06 (work | |||
in progress), November 2008. | in progress), March 2009. | |||
[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., | |||
and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", | and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", | |||
draft-ietf-httpbis-p6-cache-05 (work in progress), | draft-ietf-httpbis-p6-cache-06 (work in progress), | |||
November 2008. | March 2009. | |||
[RFC1766] Alvestrand, H., "Tags for the Identification of | [RFC1766] Alvestrand, H., "Tags for the Identification of | |||
Languages", RFC 1766, March 1995. | Languages", RFC 1766, March 1995. | |||
[RFC1864] Myers, J. and M. Rose, "The Content-MD5 Header Field", | [RFC1864] Myers, J. and M. Rose, "The Content-MD5 Header Field", | |||
RFC 1864, October 1995. | RFC 1864, October 1995. | |||
[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data 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. | |||
skipping to change at page 30, line 9 | skipping to change at page 30, line 5 | |||
[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 | |||
Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
[RFC4647] Phillips, A., Ed. and M. Davis, Ed., "Matching of Language | [RFC4647] Phillips, A., Ed. and M. Davis, Ed., "Matching of Language | |||
Tags", BCP 47, RFC 4647, September 2006. | Tags", BCP 47, RFC 4647, September 2006. | |||
10.2. Informative References | [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax | |||
Specifications: ABNF", STD 68, RFC 5234, January 2008. | ||||
9.2. Informative References | ||||
[BCP97] Klensin, J. and S. Hartman, "Handling Normative References | [BCP97] Klensin, J. and S. Hartman, "Handling Normative References | |||
to Standards-Track Documents", BCP 97, RFC 4897, | to Standards-Track Documents", BCP 97, RFC 4897, | |||
June 2007. | June 2007. | |||
[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext | [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext | |||
Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. | Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. | |||
[RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | |||
Extensions (MIME) Part Five: Conformance Criteria and | Extensions (MIME) Part Five: Conformance Criteria and | |||
skipping to change at page 32, line 9 | skipping to change at page 32, line 4 | |||
MIME-Version-v = 1*DIGIT "." 1*DIGIT | MIME-Version-v = 1*DIGIT "." 1*DIGIT | |||
MIME version "1.0" is the default for use in HTTP/1.1. However, | MIME version "1.0" is the default for use in HTTP/1.1. However, | |||
HTTP/1.1 message parsing and semantics are defined by this document | HTTP/1.1 message parsing and semantics are defined by this document | |||
and not the MIME specification. | and not the MIME specification. | |||
A.2. Conversion to Canonical Form | A.2. Conversion to Canonical Form | |||
[RFC2045] requires that an Internet mail entity be converted to | [RFC2045] requires that an Internet mail entity 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 3.3.1 of this document describes the forms | of [RFC2049]. Section 2.3.1 of this document describes the forms | |||
allowed for subtypes of the "text" media type when transmitted over | allowed for subtypes of the "text" media type when transmitted over | |||
HTTP. [RFC2046] requires that content with a type of "text" | HTTP. [RFC2046] requires that content with a type of "text" | |||
represent line breaks as CRLF and forbids the use of CR or LF outside | represent line breaks as CRLF and forbids the use of CR or LF outside | |||
of line break sequences. HTTP allows CRLF, bare CR, and bare LF to | of line break sequences. HTTP allows CRLF, bare CR, and bare LF to | |||
indicate a line break within text content when a message is | indicate a line break within text content when a message is | |||
transmitted over HTTP. | transmitted over HTTP. | |||
Where it is possible, a proxy or gateway from HTTP to a strict MIME | Where it is possible, a proxy or gateway from HTTP to a strict MIME | |||
environment SHOULD translate all line breaks within the text media | environment SHOULD translate all line breaks within the text media | |||
types described in Section 3.3.1 of this document to the RFC 2049 | types described in Section 2.3.1 of this document to the RFC 2049 | |||
canonical form of CRLF. Note, however, that this might be | canonical form of CRLF. Note, however, that this might be | |||
complicated by the presence of a Content-Encoding and by the fact | complicated by the presence of a Content-Encoding and by the fact | |||
that HTTP allows the use of some character sets which do not use | that HTTP allows the use of some character sets which do not use | |||
octets 13 and 10 to represent CR and LF, as is the case for some | octets 13 and 10 to represent CR and LF, as is the case for some | |||
multi-byte character sets. | multi-byte character sets. | |||
Implementors should note that conversion will break any cryptographic | Implementors should note that conversion will break any cryptographic | |||
checksums applied to the original content unless the original content | checksums applied to the original content unless the original content | |||
is already in canonical form. Therefore, the canonical form is | is already in canonical form. Therefore, the canonical form is | |||
recommended for any content that uses such checksums in HTTP. | recommended for any content that uses such checksums in HTTP. | |||
A.3. Introduction of Content-Encoding | A.3. Conversion of Date Formats | |||
HTTP/1.1 uses a restricted set of date formats (Section 3.2.1 of | ||||
[Part1]) to simplify the process of date comparison. Proxies and | ||||
gateways from other protocols SHOULD ensure that any Date header | ||||
field present in a message conforms to one of the HTTP/1.1 formats | ||||
and rewrite the date if necessary. | ||||
A.4. Introduction of Content-Encoding | ||||
RFC 2045 does not include any concept equivalent to HTTP/1.1's | RFC 2045 does not include any concept equivalent to HTTP/1.1's | |||
Content-Encoding header field. Since this acts as a modifier on the | Content-Encoding header field. Since this acts as a modifier on the | |||
media type, proxies and gateways from HTTP to MIME-compliant | media type, proxies and gateways from HTTP to MIME-compliant | |||
protocols MUST either change the value of the Content-Type header | protocols MUST either change the value of the Content-Type header | |||
field or decode the entity-body before forwarding the message. (Some | field or decode the entity-body before forwarding the message. (Some | |||
experimental applications of Content-Type for Internet mail have used | experimental applications of Content-Type for Internet mail have used | |||
a media-type parameter of ";conversions=<content-coding>" to perform | a media-type parameter of ";conversions=<content-coding>" to perform | |||
a function equivalent to Content-Encoding. However, this parameter | a function equivalent to Content-Encoding. However, this parameter | |||
is not part of RFC 2045). | is not part of RFC 2045). | |||
A.4. No Content-Transfer-Encoding | A.5. No Content-Transfer-Encoding | |||
HTTP does not use the Content-Transfer-Encoding field of RFC 2045. | HTTP does not use the Content-Transfer-Encoding field of RFC 2045. | |||
Proxies and gateways from MIME-compliant protocols to HTTP MUST | Proxies and gateways from MIME-compliant protocols to HTTP MUST | |||
remove any Content-Transfer-Encoding prior to delivering the response | remove any Content-Transfer-Encoding prior to delivering the response | |||
message to an HTTP client. | message to an HTTP client. | |||
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.5. Introduction of Transfer-Encoding | A.6. Introduction of Transfer-Encoding | |||
HTTP/1.1 introduces the Transfer-Encoding header field (Section 8.7 | HTTP/1.1 introduces the Transfer-Encoding header field (Section 8.7 | |||
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.6. 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, | |||
canonicalization, etc., since HTTP transports all message-bodies as | canonicalization, etc., since HTTP transports all message-bodies as | |||
payload (see Section 3.3.2) and does not interpret the content or any | payload (see Section 2.3.2) and does not interpret the content or any | |||
MIME header lines that might be contained therein. | MIME header lines that might be contained therein. | |||
Appendix B. Additional Features | Appendix B. Additional Features | |||
[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 | |||
skipping to change at page 34, line 29 | skipping to change at page 34, line 29 | |||
The receiving user agent SHOULD NOT respect any directory path | The receiving user agent SHOULD NOT respect any directory path | |||
information present in the filename-parm parameter, which is the only | information present in the filename-parm parameter, which is the only | |||
parameter believed to apply to HTTP implementations at this time. | parameter believed to apply to HTTP implementations at this time. | |||
The filename SHOULD be treated as a terminal component only. | The filename SHOULD be treated as a terminal component only. | |||
If this header is used in a response with the application/ | If this header is used in a response with the application/ | |||
octet-stream content-type, the implied suggestion is that the user | octet-stream content-type, the implied suggestion is that the user | |||
agent should not display the response, but directly enter a `save | agent should not display the response, but directly enter a `save | |||
response as...' dialog. | response as...' dialog. | |||
See Section 8.2 for Content-Disposition security issues. | See Section 7.2 for Content-Disposition security issues. | |||
Appendix C. Compatibility with Previous Versions | Appendix C. Compatibility with Previous Versions | |||
C.1. Changes from RFC 2068 | C.1. Changes from RFC 2068 | |||
Transfer-coding and message lengths all interact in ways that | Transfer-coding and message lengths all interact in ways that | |||
required fixing exactly when chunked encoding is used (to allow for | required fixing exactly when chunked encoding is used (to allow for | |||
transfer encoding that may not be self delimiting); it was important | transfer encoding that may not be self delimiting); it was important | |||
to straighten out exactly how message lengths are computed. | to straighten out exactly how message lengths are computed. | |||
(Section 4.2.2, see also [Part1], [Part5] and [Part6]). | (Section 3.2.2, see also [Part1], [Part5] and [Part6]). | |||
Charset wildcarding is introduced to avoid explosion of character set | Charset wildcarding is introduced to avoid explosion of character set | |||
names in accept headers. (Section 6.2) | names in accept headers. (Section 5.2) | |||
Content-Base was deleted from the specification: it was not | Content-Base was deleted from the specification: it was not | |||
implemented widely, and there is no simple, safe way to introduce it | implemented widely, and there is no simple, safe way to introduce it | |||
without a robust extension mechanism. In addition, it is used in a | without a robust extension mechanism. In addition, it is used in a | |||
similar, but not identical fashion in MHTML [RFC2557]. | similar, but not identical fashion in MHTML [RFC2557]. | |||
A content-coding of "identity" was introduced, to solve problems | A content-coding of "identity" was introduced, to solve problems | |||
discovered in caching. (Section 3.2) | discovered in caching. (Section 2.2) | |||
Quality Values of zero should indicate that "I don't want something" | ||||
to allow clients to refuse a representation. (Section 3.4) | ||||
The Alternates, Content-Version, Derived-From, Link, URI, Public and | The Alternates, Content-Version, Derived-From, Link, URI, Public and | |||
Content-Base header fields were defined in previous versions of this | Content-Base header fields were defined in previous versions of this | |||
specification, but not commonly implemented. See Section 19.6.2 of | specification, but not commonly implemented. See Section 19.6.2 of | |||
[RFC2068]. | [RFC2068]. | |||
C.2. Changes from RFC 2616 | C.2. Changes from RFC 2616 | |||
Clarify contexts that charset is used in. (Section 3.1) | Clarify contexts that charset is used in. (Section 2.1) | |||
Remove reference to non-existant identity transfer-coding value | Remove reference to non-existant identity transfer-coding value | |||
tokens. (Appendix A.4) | tokens. (Appendix A.5) | |||
Appendix D. Change Log (to be removed by RFC Editor before publication) | Appendix D. Collected ABNF | |||
D.1. Since RFC2616 | Accept = "Accept:" OWS Accept-v | |||
Accept-Charset = "Accept-Charset:" OWS Accept-Charset-v | ||||
Accept-Charset-v = *( "," OWS ) ( charset / "*" ) [ OWS ";" OWS "q=" | ||||
qvalue ] *( OWS "," [ OWS ( charset / "*" ) [ OWS ";" OWS "q=" | ||||
qvalue ] ] ) | ||||
Accept-Encoding = "Accept-Encoding:" OWS Accept-Encoding-v | ||||
Accept-Encoding-v = [ ( "," / ( codings [ OWS ";" OWS "q=" qvalue ] ) | ||||
) *( OWS "," [ OWS codings [ OWS ";" OWS "q=" qvalue ] ] ) ] | ||||
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 ] | ||||
] ) | ||||
Accept-v = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [ | ||||
OWS media-range [ accept-params ] ] ) ] | ||||
Content-Encoding = "Content-Encoding:" OWS Content-Encoding-v | ||||
Content-Encoding-v = *( "," OWS ) content-coding *( OWS "," [ OWS | ||||
content-coding ] ) | ||||
Content-Language = "Content-Language:" OWS Content-Language-v | ||||
Content-Language-v = *( "," OWS ) language-tag *( OWS "," [ OWS | ||||
language-tag ] ) | ||||
Content-Length = <Content-Length, defined in [Part1], Section 8.2> | ||||
Content-Location = "Content-Location:" OWS Content-Location-v | ||||
Content-Location-v = absolute-URI / partial-URI | ||||
Content-MD5 = "Content-MD5:" OWS Content-MD5-v | ||||
Content-MD5-v = <base64 of 128 bit MD5 digest as per [RFC1864]> | ||||
Content-Range = <Content-Range, defined in [Part5], Section 5.2> | ||||
Content-Type = "Content-Type:" OWS Content-Type-v | ||||
Content-Type-v = media-type | ||||
Expires = <Expires, defined in [Part6], Section 3.3> | ||||
Last-Modified = <Last-Modified, defined in [Part4], Section 6.6> | ||||
MIME-Version = "MIME-Version:" OWS MIME-Version-v | ||||
MIME-Version-v = 1*DIGIT "." 1*DIGIT | ||||
OWS = <OWS, defined in [Part1], Section 1.2.2> | ||||
absolute-URI = <absolute-URI, defined in [Part1], Section 2.1> | ||||
accept-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ] | ||||
accept-params = OWS ";" OWS "q=" qvalue *accept-ext | ||||
attribute = token | ||||
charset = token | ||||
codings = ( content-coding / "*" ) | ||||
content-coding = token | ||||
content-disposition = "Content-Disposition:" OWS | ||||
content-disposition-v | ||||
content-disposition-v = disposition-type *( OWS ";" OWS | ||||
disposition-parm ) | ||||
disp-extension-parm = token "=" ( token / quoted-string ) | ||||
disp-extension-token = token | ||||
disposition-parm = filename-parm / disp-extension-parm | ||||
disposition-type = "attachment" / disp-extension-token | ||||
entity-body = *OCTET | ||||
entity-header = Content-Encoding / Content-Language / Content-Length | ||||
/ Content-Location / Content-MD5 / Content-Range / Content-Type / | ||||
Expires / Last-Modified / extension-header | ||||
extension-header = message-header | ||||
filename-parm = "filename=" quoted-string | ||||
language-range = <language-range, defined in [RFC4647], Section 2.1> | ||||
language-tag = primary-tag *( "-" subtag ) | ||||
media-range = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS | ||||
";" OWS parameter ) | ||||
media-type = type "/" subtype *( OWS ";" OWS parameter ) | ||||
message-header = <message-header, defined in [Part1], Section 4.2> | ||||
parameter = attribute "=" value | ||||
partial-URI = <partial-URI, defined in [Part1], Section 2.1> | ||||
primary-tag = 1*8ALPHA | ||||
quoted-string = <quoted-string, defined in [Part1], Section 1.2.2> | ||||
qvalue = <qvalue, defined in [Part1], Section 3.5> | ||||
subtag = 1*8ALPHA | ||||
subtype = token | ||||
token = <token, defined in [Part1], Section 1.2.2> | ||||
type = token | ||||
value = token / quoted-string | ||||
ABNF diagnostics: | ||||
; Accept defined but not used | ||||
; Accept-Charset defined but not used | ||||
; Accept-Encoding defined but not used | ||||
; Accept-Language defined but not used | ||||
; MIME-Version defined but not used | ||||
; content-disposition defined but not used | ||||
; entity-body defined but not used | ||||
; entity-header defined but not used | ||||
Appendix E. Change Log (to be removed by RFC Editor before publication) | ||||
E.1. Since RFC2616 | ||||
Extracted relevant partitions from [RFC2616]. | Extracted relevant partitions from [RFC2616]. | |||
D.2. Since draft-ietf-httpbis-p3-payload-00 | E.2. Since draft-ietf-httpbis-p3-payload-00 | |||
Closed issues: | Closed issues: | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/8>: "Media Type | o <http://tools.ietf.org/wg/httpbis/trac/ticket/8>: "Media Type | |||
Registrations" (<http://purl.org/NET/http-errata#media-reg>) | Registrations" (<http://purl.org/NET/http-errata#media-reg>) | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/14>: "Clarification | o <http://tools.ietf.org/wg/httpbis/trac/ticket/14>: "Clarification | |||
regarding quoting of charset values" | regarding quoting of charset values" | |||
(<http://purl.org/NET/http-errata#charactersets>) | (<http://purl.org/NET/http-errata#charactersets>) | |||
skipping to change at page 36, line 16 | skipping to change at page 38, line 19 | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/66>: "ISO-8859-1 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/66>: "ISO-8859-1 | |||
Reference" | Reference" | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/68>: "Encoding | o <http://tools.ietf.org/wg/httpbis/trac/ticket/68>: "Encoding | |||
References Normative" | References Normative" | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/86>: "Normative up- | o <http://tools.ietf.org/wg/httpbis/trac/ticket/86>: "Normative up- | |||
to-date references" | to-date references" | |||
D.3. Since draft-ietf-httpbis-p3-payload-01 | E.3. Since draft-ietf-httpbis-p3-payload-01 | |||
Ongoing work on ABNF conversion | Ongoing work on ABNF conversion | |||
(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): | (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): | |||
o Add explicit references to BNF syntax and rules imported from | o Add explicit references to BNF syntax and rules imported from | |||
other parts of the specification. | other parts of the specification. | |||
D.4. Since draft-ietf-httpbis-p3-payload-02 | E.4. Since draft-ietf-httpbis-p3-payload-02 | |||
Closed issues: | Closed issues: | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/67>: "Quoting | o <http://tools.ietf.org/wg/httpbis/trac/ticket/67>: "Quoting | |||
Charsets" | Charsets" | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/105>: | o <http://tools.ietf.org/wg/httpbis/trac/ticket/105>: | |||
"Classification for Allow header" | "Classification for Allow header" | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/115>: "missing | o <http://tools.ietf.org/wg/httpbis/trac/ticket/115>: "missing | |||
default for qvalue in description of Accept-Encoding" | default for qvalue in description of Accept-Encoding" | |||
Ongoing work on IANA Message Header Registration | Ongoing work on IANA Message Header Registration | |||
(<http://tools.ietf.org/wg/httpbis/trac/ticket/40>): | (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>): | |||
o Reference RFC 3984, and update header registrations for headers | o Reference RFC 3984, and update header registrations for headers | |||
defined in this document. | defined in this document. | |||
D.5. Since draft-ietf-httpbis-p3-payload-03 | E.5. Since draft-ietf-httpbis-p3-payload-03 | |||
Closed issues: | Closed issues: | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/67>: "Quoting | o <http://tools.ietf.org/wg/httpbis/trac/ticket/67>: "Quoting | |||
Charsets" | Charsets" | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/113>: "language tag | o <http://tools.ietf.org/wg/httpbis/trac/ticket/113>: "language tag | |||
matching (Accept-Language) vs RFC4647" | matching (Accept-Language) vs RFC4647" | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/121>: "RFC 1806 has | o <http://tools.ietf.org/wg/httpbis/trac/ticket/121>: "RFC 1806 has | |||
been replaced by RFC2183" | been replaced by RFC2183" | |||
Other changes: | Other changes: | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/68>: "Encoding | o <http://tools.ietf.org/wg/httpbis/trac/ticket/68>: "Encoding | |||
References Normative" -- rephrase the annotation and reference | References Normative" -- rephrase the annotation and reference | |||
[BCP97]. | [BCP97]. | |||
D.6. Since draft-ietf-httpbis-p3-payload-04 | E.6. Since draft-ietf-httpbis-p3-payload-04 | |||
Closed issues: | Closed issues: | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/132>: "RFC 2822 is | o <http://tools.ietf.org/wg/httpbis/trac/ticket/132>: "RFC 2822 is | |||
updated by RFC 5322" | updated by RFC 5322" | |||
Ongoing work on ABNF conversion | Ongoing work on ABNF conversion | |||
(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): | (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): | |||
o Use "/" instead of "|" for alternatives. | o Use "/" instead of "|" for alternatives. | |||
o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional | o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional | |||
whitespace ("OWS") and required whitespace ("RWS"). | whitespace ("OWS") and required whitespace ("RWS"). | |||
o Rewrite ABNFs to spell out whitespace rules, factor out header | o Rewrite ABNFs to spell out whitespace rules, factor out header | |||
value format definitions. | value format definitions. | |||
E.7. Since draft-ietf-httpbis-p3-payload-05 | ||||
Closed issues: | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/118>: "Join | ||||
"Differences Between HTTP Entities and RFC 2045 Entities"?" | ||||
Final work on ABNF conversion | ||||
(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): | ||||
o Add appendix containing collected and expanded ABNF, reorganize | ||||
ABNF introduction. | ||||
Other changes: | ||||
o Move definition of quality values into Part 1. | ||||
Index | Index | |||
A | A | |||
Accept header 16 | Accept header 16 | |||
Accept-Charset header 18 | Accept-Charset header 18 | |||
Accept-Encoding header 19 | Accept-Encoding header 19 | |||
Accept-Language header 20 | Accept-Language header 20 | |||
Alternates header 35 | Alternates header 35 | |||
C | C | |||
compress 8 | compress 8 | |||
Content-Base header 35 | Content-Base header 35 | |||
Content-Disposition header 33 | Content-Disposition header 33 | |||
Content-Encoding header 22 | Content-Encoding header 22 | |||
Content-Language header 23 | Content-Language header 23 | |||
Content-Location header 24 | Content-Location header 23 | |||
Content-MD5 header 24 | Content-MD5 header 24 | |||
Content-Type header 26 | Content-Type header 26 | |||
Content-Version header 35 | Content-Version header 35 | |||
D | D | |||
deflate 8 | deflate 8 | |||
Derived-From header 35 | Derived-From header 35 | |||
G | G | |||
Grammar | Grammar | |||
Accept 16 | Accept 16 | |||
Accept-Charset 18 | Accept-Charset 18 | |||
Accept-Charset-v 18 | Accept-Charset-v 18 | |||
Accept-Encoding 19 | Accept-Encoding 19 | |||
skipping to change at page 38, line 16 | skipping to change at page 40, line 37 | |||
Derived-From header 35 | Derived-From header 35 | |||
G | G | |||
Grammar | Grammar | |||
Accept 16 | Accept 16 | |||
Accept-Charset 18 | Accept-Charset 18 | |||
Accept-Charset-v 18 | Accept-Charset-v 18 | |||
Accept-Encoding 19 | Accept-Encoding 19 | |||
Accept-Encoding-v 19 | Accept-Encoding-v 19 | |||
accept-ext 16 | accept-ext 16 | |||
Accept-Language 21 | Accept-Language 20 | |||
Accept-Language-v 21 | Accept-Language-v 20 | |||
accept-params 16 | accept-params 16 | |||
Accept-v 16 | Accept-v 16 | |||
attribute 9 | attribute 9 | |||
charset 6 | charset 7 | |||
codings 19 | codings 19 | |||
content-coding 7 | content-coding 8 | |||
content-disposition 34 | content-disposition 34 | |||
content-disposition-v 34 | content-disposition-v 34 | |||
Content-Encoding 22 | Content-Encoding 22 | |||
Content-Encoding-v 22 | Content-Encoding-v 22 | |||
Content-Language 23 | Content-Language 23 | |||
Content-Language-v 23 | Content-Language-v 23 | |||
Content-Location 24 | Content-Location 24 | |||
Content-Location-v 24 | Content-Location-v 24 | |||
Content-MD5 25 | Content-MD5 24 | |||
Content-MD5-v 25 | Content-MD5-v 24 | |||
Content-Type 26 | Content-Type 26 | |||
Content-Type-v 26 | Content-Type-v 26 | |||
disp-extension-parm 34 | disp-extension-parm 34 | |||
disp-extension-token 34 | disp-extension-token 34 | |||
disposition-parm 34 | disposition-parm 34 | |||
disposition-type 34 | disposition-type 34 | |||
entity-body 12 | entity-body 12 | |||
entity-header 12 | entity-header 12 | |||
extension-header 12 | extension-header 12 | |||
filename-parm 34 | filename-parm 34 | |||
language-range 21 | language-range 20 | |||
language-tag 11 | language-tag 11 | |||
media-range 16 | media-range 16 | |||
media-type 9 | media-type 9 | |||
MIME-Version 31 | MIME-Version 31 | |||
MIME-Version-v 31 | MIME-Version-v 31 | |||
parameter 9 | parameter 9 | |||
primary-tag 11 | primary-tag 11 | |||
qvalue 11 | ||||
subtag 11 | subtag 11 | |||
subtype 9 | subtype 9 | |||
type 9 | type 9 | |||
value 9 | value 9 | |||
gzip 8 | gzip 8 | |||
H | H | |||
Headers | Headers | |||
Accept 16 | Accept 16 | |||
Accept-Charset 18 | Accept-Charset 18 | |||
Accept-Encoding 19 | Accept-Encoding 19 | |||
Accept-Language 20 | Accept-Language 20 | |||
Alternate 35 | Alternate 35 | |||
Content-Base 35 | Content-Base 35 | |||
Content-Disposition 33 | Content-Disposition 33 | |||
Content-Encoding 22 | Content-Encoding 22 | |||
Content-Language 23 | Content-Language 23 | |||
Content-Location 24 | Content-Location 23 | |||
Content-MD5 24 | Content-MD5 24 | |||
Content-Type 26 | Content-Type 26 | |||
Content-Version 35 | Content-Version 35 | |||
Derived-From 35 | Derived-From 35 | |||
Link 35 | Link 35 | |||
MIME-Version 31 | MIME-Version 31 | |||
Public 35 | Public 35 | |||
URI 35 | URI 35 | |||
I | I | |||
skipping to change at page 43, line 4 | skipping to change at line 2010 | |||
Julian F. Reschke (editor) | Julian F. Reschke (editor) | |||
greenbytes GmbH | greenbytes GmbH | |||
Hafenweg 16 | Hafenweg 16 | |||
Muenster, NW 48155 | Muenster, NW 48155 | |||
Germany | Germany | |||
Phone: +49 251 2807760 | Phone: +49 251 2807760 | |||
Fax: +49 251 2807761 | Fax: +49 251 2807761 | |||
Email: julian.reschke@greenbytes.de | Email: julian.reschke@greenbytes.de | |||
URI: http://greenbytes.de/tech/webdav/ | URI: http://greenbytes.de/tech/webdav/ | |||
Full Copyright Statement | ||||
Copyright (C) The IETF Trust (2008). | ||||
This document is subject to the rights, licenses and restrictions | ||||
contained in BCP 78, and except as set forth therein, the authors | ||||
retain all their rights. | ||||
This document and the information contained herein are provided on an | ||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | ||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND | ||||
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS | ||||
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF | ||||
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | ||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | ||||
Intellectual Property | ||||
The IETF takes no position regarding the validity or scope of any | ||||
Intellectual Property Rights or other rights that might be claimed to | ||||
pertain to the implementation or use of the technology described in | ||||
this document or the extent to which any license under such rights | ||||
might or might not be available; nor does it represent that it has | ||||
made any independent effort to identify any such rights. Information | ||||
on the procedures with respect to rights in RFC documents can be | ||||
found in BCP 78 and BCP 79. | ||||
Copies of IPR disclosures made to the IETF Secretariat and any | ||||
assurances of licenses to be made available, or the result of an | ||||
attempt made to obtain a general license or permission for the use of | ||||
such proprietary rights by implementers or users of this | ||||
specification can be obtained from the IETF on-line IPR repository at | ||||
http://www.ietf.org/ipr. | ||||
The IETF invites any interested party to bring to its attention any | ||||
copyrights, patents or patent applications, or other proprietary | ||||
rights that may cover technology that may be required to implement | ||||
this standard. Please address the information to the IETF at | ||||
ietf-ipr@ietf.org. | ||||
End of changes. 129 change blocks. | ||||
235 lines changed or deleted | 387 lines changed or added | |||
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |