| draft-ietf-httpbis-p3-payload-00.txt |  | draft-ietf-httpbis-p3-payload-01.txt |
--- | --- | --- | --- | ---
| Network Working Group R. Fielding, Ed. |  | Network Working Group R. Fielding, Ed. |
| Internet-Draft Day Software |  | Internet-Draft Day Software |
| Obsoletes: 2068, 2616 J. Gettys |  | Obsoletes: 2616 (if approved) J. Gettys |
| (if approved) One Laptop per Child |  | Intended status: Standards Track One Laptop per Child |
| Intended status: Standards Track J. Mogul |  | Expires: July 15, 2008 J. Mogul |
| Expires: June 22, 2008 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 |
| December 20, 2007 |  | Y. Lafon, Ed. |
|  |  | W3C |
|  |  | J. Reschke, Ed. |
|  |  | greenbytes |
|  |  | January 12, 2008 |
| 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-00 |  | draft-ietf-httpbis-p3-payload-01 |
| Status of this Memo |  | Status of this Memo |
| By submitting this Internet-Draft, each author represents that any |  | By submitting this Internet-Draft, each author represents that any |
| applicable patent or other IPR claims of which he or she is aware |  | applicable patent or other IPR claims of which he or she is aware |
| have been or will be disclosed, and any of which he or she becomes |  | have been or will be disclosed, and any of which he or she becomes |
| aware will be disclosed, in accordance with Section 6 of BCP 79. |  | aware will be disclosed, in accordance with Section 6 of BCP 79. |
| 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 |
| skipping to change at page 1, line 45 |  | skipping to change at page 1, line 49 |
| 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 June 22, 2008. |  | This Internet-Draft will expire on July 15, 2008. |
| Copyright Notice |  | Copyright Notice |
| Copyright (C) The IETF Trust (2007). |  | Copyright (C) The IETF Trust (2008). |
| 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) |
| This version of the HTTP specification contains only minimal |  |  |
| editorial changes from [RFC2616] (abstract, introductory paragraph, |  |  |
| and authors' addresses). All other changes are due to partitioning |  |  |
| the original into seven mostly independent parts. The intent is for |  |  |
| readers of future drafts to able to use draft 00 as the basis for |  |  |
| comparison when the WG makes later changes to the specification text. |  |  |
| This draft will shortly be followed by draft 01 (containing the first |  |  |
| round of changes that have already been agreed to on the mailing |  |  |
| list). There is no point in reviewing this draft other than to |  |  |
| verify that the partitioning has been done correctly. Roy T. |  |  |
| Fielding, Yves Lafon, and Julian Reschke will be the editors after |  |  |
| draft 00 is submitted. |  |  |
| 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://www3.tools.ietf.org/wg/httpbis/trac/report/11> and related |  | at <http://www.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://www3.tools.ietf.org/wg/httpbis/>. |  | <http://www.tools.ietf.org/wg/httpbis/>. |
|  |  | This draft incorporates those issue resolutions that were either |
|  |  | collected in the original RFC2616 errata list |
|  |  | (<http://purl.org/NET/http-errata>), or which were agreed upon on the |
|  |  | mailing list between October 2006 and November 2007 (as published in |
|  |  | "draft-lafon-rfc2616bis-03"). |
| Table of Contents |  | Table of Contents |
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 |  | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 |
|  |  | 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 |
| 2. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 5 |  | 2. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 5 |
| 2.1. Character Sets . . . . . . . . . . . . . . . . . . . . . . 5 |  | 2.1. Character Sets . . . . . . . . . . . . . . . . . . . . . . 5 |
| 2.1.1. Missing Charset . . . . . . . . . . . . . . . . . . . 6 |  | 2.1.1. Missing Charset . . . . . . . . . . . . . . . . . . . 6 |
| 2.2. Content Codings . . . . . . . . . . . . . . . . . . . . . 6 |  | 2.2. Content Codings . . . . . . . . . . . . . . . . . . . . . 7 |
| 2.3. Media Types . . . . . . . . . . . . . . . . . . . . . . . 7 |  | 2.3. Media Types . . . . . . . . . . . . . . . . . . . . . . . 8 |
| 2.3.1. Canonicalization and Text Defaults . . . . . . . . . . 8 |  | 2.3.1. Canonicalization and Text Defaults . . . . . . . . . . 9 |
| 2.3.2. Multipart Types . . . . . . . . . . . . . . . . . . . 9 |  | 2.3.2. Multipart Types . . . . . . . . . . . . . . . . . . . 9 |
| 2.4. Quality Values . . . . . . . . . . . . . . . . . . . . . . 9 |  | 2.4. Quality Values . . . . . . . . . . . . . . . . . . . . . . 10 |
| 2.5. Language Tags . . . . . . . . . . . . . . . . . . . . . . 10 |  | 2.5. Language Tags . . . . . . . . . . . . . . . . . . . . . . 10 |
| 3. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 |  | 3. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 |
| 3.1. Entity Header Fields . . . . . . . . . . . . . . . . . . . 10 |  | 3.1. Entity Header Fields . . . . . . . . . . . . . . . . . . . 11 |
| 3.2. Entity Body . . . . . . . . . . . . . . . . . . . . . . . 11 |  | 3.2. Entity Body . . . . . . . . . . . . . . . . . . . . . . . 12 |
| 3.2.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 11 |  | 3.2.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 12 |
| 3.2.2. Entity Length . . . . . . . . . . . . . . . . . . . . 12 |  | 3.2.2. Entity Length . . . . . . . . . . . . . . . . . . . . 12 |
| 4. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 12 |  | 4. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 13 |
| 4.1. Server-driven Negotiation . . . . . . . . . . . . . . . . 12 |  | 4.1. Server-driven Negotiation . . . . . . . . . . . . . . . . 13 |
| 4.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . . 14 |  | 4.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . . 14 |
| 4.3. Transparent Negotiation . . . . . . . . . . . . . . . . . 14 |  | 4.3. Transparent Negotiation . . . . . . . . . . . . . . . . . 15 |
| 5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 15 |  | 5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 15 |
| 5.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . . 15 |  | 5.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . . 16 |
| 5.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . . 17 |  | 5.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . . 18 |
| 5.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 17 |  | 5.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 18 |
| 5.4. Accept-Language . . . . . . . . . . . . . . . . . . . . . 19 |  | 5.4. Accept-Language . . . . . . . . . . . . . . . . . . . . . 20 |
| 5.5. Content-Encoding . . . . . . . . . . . . . . . . . . . . . 20 |  | 5.5. Content-Encoding . . . . . . . . . . . . . . . . . . . . . 21 |
| 5.6. Content-Language . . . . . . . . . . . . . . . . . . . . . 21 |  | 5.6. Content-Language . . . . . . . . . . . . . . . . . . . . . 22 |
| 5.7. Content-Location . . . . . . . . . . . . . . . . . . . . . 22 |  | 5.7. Content-Location . . . . . . . . . . . . . . . . . . . . . 22 |
| 5.8. Content-MD5 . . . . . . . . . . . . . . . . . . . . . . . 22 |  | 5.8. Content-MD5 . . . . . . . . . . . . . . . . . . . . . . . 23 |
| 5.9. Content-Type . . . . . . . . . . . . . . . . . . . . . . . 24 |  | 5.9. Content-Type . . . . . . . . . . . . . . . . . . . . . . . 24 |
| 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 |  | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 |
| 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 |  | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 |
| 7.1. Privacy Issues Connected to Accept Headers . . . . . . . . 24 |  | 7.1. Privacy Issues Connected to Accept Headers . . . . . . . . 25 |
| 7.2. Content-Disposition Issues . . . . . . . . . . . . . . . . 25 |  | 7.2. Content-Disposition Issues . . . . . . . . . . . . . . . . 26 |
| 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 |  | 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 |
| 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 |  | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 |
|  |  | 9.1. Normative References . . . . . . . . . . . . . . . . . . . 26 |
|  |  | 9.2. Informative References . . . . . . . . . . . . . . . . . . 28 |
| Appendix A. Differences Between HTTP Entities and RFC 2045 |  | Appendix A. Differences Between HTTP Entities and RFC 2045 |
| Entities . . . . . . . . . . . . . . . . . . . . . . 27 |  | Entities . . . . . . . . . . . . . . . . . . . . . . 29 |
| A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 28 |  | A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 29 |
| A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 28 |  | A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 30 |
| A.3. Introduction of Content-Encoding . . . . . . . . . . . . . 29 |  | A.3. Introduction of Content-Encoding . . . . . . . . . . . . . 30 |
| A.4. No Content-Transfer-Encoding . . . . . . . . . . . . . . . 29 |  | A.4. No Content-Transfer-Encoding . . . . . . . . . . . . . . . 30 |
| A.5. Introduction of Transfer-Encoding . . . . . . . . . . . . 29 |  | A.5. Introduction of Transfer-Encoding . . . . . . . . . . . . 31 |
| A.6. MHTML and Line Length Limitations . . . . . . . . . . . . 29 |  | A.6. MHTML and Line Length Limitations . . . . . . . . . . . . 31 |
| Appendix B. Additional Features . . . . . . . . . . . . . . . . . 30 |  | Appendix B. Additional Features . . . . . . . . . . . . . . . . . 31 |
| B.1. Content-Disposition . . . . . . . . . . . . . . . . . . . 30 |  | B.1. Content-Disposition . . . . . . . . . . . . . . . . . . . 31 |
| Appendix C. Changes from RFC 2068 . . . . . . . . . . . . . . . . 31 |  | Appendix C. Compatibility with Previous Versions . . . . . . . . 32 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 |  | C.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 32 |
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 |  | C.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 33 |
| Intellectual Property and Copyright Statements . . . . . . . . . . 36 |  | Appendix D. Change Log (to be removed by RFC Editor before |
|  |  | publication) . . . . . . . . . . . . . . . . . . . . 33 |
|  |  | D.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 33 |
|  |  | D.2. Since draft-ietf-httpbis-p3-payload-00 . . . . . . . . . . 33 |
|  |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 |
|  |  | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 |
|  |  | Intellectual Property and Copyright Statements . . . . . . . . . . 39 |
| 1. Introduction |  | 1. Introduction |
| This document will define aspects of HTTP related to the payload of |  | This document defines HTTP/1.1 message payloads (a.k.a., content), |
| messages (message content), including metadata and media types, along |  | the associated metadata header fields that define how the payload is |
| with HTTP content negotiation. Right now it only includes the |  | intended to be interpreted by a recipient, the request header fields |
| extracted relevant sections of RFC 2616 without edit. |  | that may influence content selection, and the various selection |
|  |  | algorithms that are collectively referred to as HTTP content |
|  |  | negotiation. |
|  |  | This document is currently disorganized in order to minimize the |
|  |  | changes between drafts and enable reviewers to see the smaller errata |
|  |  | changes. The next draft will reorganize the sections to better |
|  |  | reflect the content. In particular, the sections on entities will be |
|  |  | renamed payload and moved to the first half of the document, while |
|  |  | the sections on content negotiation and associated request header |
|  |  | fields will be moved to the second half. The current mess reflects |
|  |  | how widely dispersed these topics and associated requirements had |
|  |  | become in [RFC2616]. |
|  |  | 1.1. Requirements |
|  |  | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |
|  |  | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |
|  |  | document are to be interpreted as described in [RFC2119]. |
|  |  | An implementation is not compliant if it fails to satisfy one or more |
|  |  | of the MUST or REQUIRED level requirements for the protocols it |
|  |  | implements. An implementation that satisfies all the MUST or |
|  |  | REQUIRED level and all the SHOULD level requirements for its |
|  |  | protocols is said to be "unconditionally compliant"; one that |
|  |  | satisfies all the MUST level requirements but not all the SHOULD |
|  |  | level requirements for its protocols is said to be "conditionally |
|  |  | compliant." |
| 2. Protocol Parameters |  | 2. Protocol Parameters |
| 2.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 |
| skipping to change at page 5, line 40 |  | skipping to change at page 6, line 20 |
| to characters. In particular, use of external profiling information |  | to characters. In particular, use of external profiling information |
| to determine the exact mapping is not permitted. |  | to determine the exact mapping is not permitted. |
| Note: This use of the term "character set" is more commonly |  | Note: This use of the term "character set" is more commonly |
| referred to as a "character encoding." However, since HTTP and |  | referred to as a "character encoding." However, since HTTP and |
| MIME share the same registry, it is important that the terminology |  | MIME share the same registry, it is important that the terminology |
| also be shared. |  | also be shared. |
| HTTP character sets are identified by case-insensitive tokens. The |  | HTTP character sets are identified by case-insensitive tokens. The |
| complete set of tokens is defined by the IANA Character Set registry |  | complete set of tokens is defined by the IANA Character Set registry |
| [RFC1700]. |  | (<http://www.iana.org/assignments/character-sets>). |
| charset = token |  | charset = token |
| Although HTTP allows an arbitrary token to be used as a charset |  | Although HTTP allows an arbitrary token to be used as a charset |
| value, any token that has a predefined value within the IANA |  | value, any token that has a predefined value within the IANA |
| Character Set registry [RFC1700] MUST represent the character set |  | Character Set registry MUST represent the character set defined by |
| defined by that registry. Applications SHOULD limit their use of |  | that registry. Applications SHOULD limit their use of character sets |
| character sets to those defined by the IANA registry. |  | to those defined by the IANA registry. |
|  |  | HTTP uses charset in two contexts: within an Accept-Charset request |
|  |  | 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 |
|  |  | response), in which case the parameter value of the charset parameter |
|  |  | may be quoted. |
| Implementors should be aware of IETF character set requirements |  | Implementors should be aware of IETF character set requirements |
| [RFC2279] [RFC2277]. |  | [RFC3629] [RFC2277]. |
| 2.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 and SHOULD do so when |  | parameter even when the charset is ISO-8859-1 ([ISO-8859-1]) and |
| 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 2.3.1. |  | Section 2.3.1. |
| 2.2. Content Codings |  | 2.2. Content Codings |
| skipping to change at page 6, line 46 |  | skipping to change at page 7, line 31 |
| 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 |
| An encoding format produced by the file compression program "gzip" |  | An encoding format produced by the file compression program "gzip" |
| (GNU zip) as described in RFC 1952 [RFC1952]. This format is a |  | (GNU zip) as described in [RFC1952]. This format is a Lempel-Ziv |
| Lempel-Ziv coding (LZ77) with a 32 bit CRC. |  | coding (LZ77) with a 32 bit CRC. |
| compress |  | compress |
| The encoding format produced by the common UNIX file compression |  | The encoding format produced by the common UNIX file compression |
| program "compress". This format is an adaptive Lempel-Ziv-Welch |  | program "compress". This format is an adaptive Lempel-Ziv-Welch |
| coding (LZW). |  | coding (LZW). |
| Use of program names for the identification of encoding formats is |  | Use of program names for the identification of encoding formats is |
| not desirable and is discouraged for future encodings. Their use |  | not desirable and is discouraged for future encodings. Their use |
| here is representative of historical practice, not good design. |  | here is representative of historical practice, not good design. |
| For compatibility with previous implementations of HTTP, |  | For compatibility with previous implementations of HTTP, |
| applications SHOULD consider "x-gzip" and "x-compress" to be |  | applications SHOULD consider "x-gzip" and "x-compress" to be |
| equivalent to "gzip" and "compress" respectively. |  | equivalent to "gzip" and "compress" respectively. |
| deflate |  | deflate |
| The "zlib" format defined in RFC 1950 [RFC1950] in combination |  | The "zlib" format defined in [RFC1950] in combination with the |
| with the "deflate" compression mechanism described in RFC 1951 |  | "deflate" compression mechanism described in [RFC1951]. |
| [RFC1951]. |  |  |
| identity |  | identity |
| The default (identity) encoding; the use of no transformation |  | The default (identity) encoding; the use of no transformation |
| 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. |
| 2.3. Media Types |  | 2.3. Media Types |
| HTTP uses Internet Media Types [RFC1590] in the Content-Type |  | HTTP uses Internet Media Types [RFC2046] in the Content-Type |
| (Section 5.9) and Accept (Section 5.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 *( ";" parameter ) |  | media-type = type "/" subtype *( ";" 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. |
| skipping to change at page 8, line 15 |  | skipping to change at page 8, line 49 |
| attribute and its value. The presence or absence of a parameter |  | attribute and its value. The presence or absence of a parameter |
| might be significant to the processing of a media-type, depending on |  | might be significant to the processing of a media-type, depending on |
| its definition within the media type registry. |  | its definition within the media type registry. |
| 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 [RFC1700]). The media type registration process is |  | Authority (IANA). The media type registration process is outlined in |
| outlined in RFC 1590 [RFC1590]. Use of non-registered media types is |  | [RFC4288]. Use of non-registered media types is discouraged. |
| discouraged. |  |  |
| 2.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 |
| skipping to change at page 9, line 9 |  | skipping to change at page 9, line 42 |
| 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 2.1.1 for compatibility problems. |  | Section 2.1.1 for compatibility problems. |
| 2.3.2. Multipart Types |  | 2.3.2. Multipart Types |
| MIME provides for a number of "multipart" types -- encapsulations of |  | MIME provides for a number of "multipart" types -- encapsulations of |
| one or more 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 RFC 2046 |  | 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 |
| in order to preserve the self-delimiting nature of a multipart |  | in order to preserve the self-delimiting nature of a multipart |
| message-body, wherein the "end" of the message-body is indicated by |  | message-body, wherein the "end" of the message-body is indicated by |
| the ending multipart boundary. |  | the ending multipart boundary. |
| skipping to change at page 9, line 36 |  | skipping to change at page 10, line 21 |
| within each body-part of a multipart message-body do not have any |  | within each body-part of a multipart message-body do not have any |
| significance to HTTP beyond that defined by their MIME semantics. |  | significance to HTTP beyond that defined by their MIME semantics. |
| 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 RFC 1867 [RFC1867]. |  | request method, as described in [RFC2388]. |
| 2.4. Quality Values |  | 2.4. Quality Values |
| HTTP content negotiation (Section 4) uses short "floating point" |  | HTTP content negotiation (Section 4) uses short "floating point" |
| numbers to indicate the relative importance ("weight") of various |  | numbers to indicate the relative importance ("weight") of various |
| negotiable parameters. A weight is normalized to a real number in |  | 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 |  | 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 |  | value. If a parameter has a quality value of 0, then content with |
| this parameter is `not acceptable' for the client. HTTP/1.1 |  | this parameter is `not acceptable' for the client. HTTP/1.1 |
| applications MUST NOT generate more than three digits after the |  | applications MUST NOT generate more than three digits after the |
| skipping to change at page 10, line 16 |  | skipping to change at page 10, line 50 |
| 2.5. Language Tags |  | 2.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 RFC 1766 [RFC1766]. In summary, a language tag is |  | defined by [RFC1766]. In summary, a language tag is composed of 1 or |
| composed of 1 or more parts: A primary language tag and a possibly |  | more parts: A primary language tag and a possibly empty series of |
| empty series of subtags: |  | subtags: |
| language-tag = primary-tag *( "-" subtag ) |  | language-tag = primary-tag *( "-" subtag ) |
| primary-tag = 1*8ALPHA |  | primary-tag = 1*8ALPHA |
| subtag = 1*8ALPHA |  | subtag = 1*8ALPHA |
| White space is not allowed within the tag and all tags are case- |  | White space is not allowed within the tag and all tags are case- |
| 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 |
| skipping to change at page 10, line 49 |  | skipping to change at page 11, line 34 |
| 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. |
| 3.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. |
| Some of this metainformation is OPTIONAL; some might be REQUIRED by |  |  |
| portions of this specification. |  |  |
| entity-header = Allow ; [Part2], Section 10.1 |  | entity-header = Allow ; [Part2], Section 10.1 |
| | Content-Encoding ; Section 5.5 |  | | Content-Encoding ; Section 5.5 |
| | Content-Language ; Section 5.6 |  | | Content-Language ; Section 5.6 |
| | Content-Length ; [Part1], Section 8.2 |  | | Content-Length ; [Part1], Section 8.2 |
| | Content-Location ; Section 5.7 |  | | Content-Location ; Section 5.7 |
| | Content-MD5 ; Section 5.8 |  | | Content-MD5 ; Section 5.8 |
| | Content-Range ; [Part5], Section 5.2 |  | | Content-Range ; [Part5], Section 5.2 |
| | Content-Type ; Section 5.9 |  | | Content-Type ; Section 5.9 |
| | Expires ; [Part6], Section 3.3 |  | | Expires ; [Part6], Section 15.3 |
| | Last-Modified ; [Part4], Section 6.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. |
| skipping to change at page 13, line 48 |  | skipping to change at page 14, line 34 |
| 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 5.1), Accept- |  | capabilities and user preferences: Accept (Section 5.1), Accept- |
| Charset (Section 5.2), Accept-Encoding (Section 5.3), Accept-Language |  | Charset (Section 5.2), Accept-Encoding (Section 5.3), Accept-Language |
| (Section 5.4), and User-Agent (Section 10.9 of [Part2]). However, an |  | (Section 5.4), and User-Agent (Section 10.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 [Part6] can be used to express the parameters |  | The Vary header field (Section 15.5 of [Part6]) can be used to |
| the server uses to select a representation that is subject to server- |  | express the parameters the server uses to select a representation |
| driven negotiation. |  | that is subject to server-driven negotiation. |
| 4.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 |
| skipping to change at page 15, line 9 |  | skipping to change at page 15, line 42 |
| 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. |
| 5. Header Field Definitions |  | 5. Header Field Definitions |
| This section defines the syntax and semantics of all standard |  | This section defines the syntax and semantics of HTTP/1.1 header |
| HTTP/1.1 header fields. For entity-header fields, both sender and |  | fields related to the payload of messages. |
| recipient refer to either the client or the server, depending on who |  |  |
| sends and who receives the entity. |  | For entity-header fields, both sender and recipient refer to either |
|  |  | the client or the server, depending on who sends and who receives the |
|  |  | entity. |
| 5.1. Accept |  | 5.1. Accept |
| The Accept request-header field can be used to specify certain media |  | The Accept request-header field can be used to specify certain media |
| types which are acceptable for the response. Accept headers can be |  | types which are acceptable for the response. Accept headers can be |
| used to indicate that the request is specifically limited to a small |  | 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-line |  | set of desired types, as in the case of a request for an in-line |
| image. |  | image. |
| Accept = "Accept" ":" |  | Accept = "Accept" ":" |
| skipping to change at page 16, line 18 |  | skipping to change at page 17, line 7 |
| Accept: audio/*; q=0.2, audio/basic |  | Accept: audio/*; q=0.2, audio/basic |
| SHOULD be interpreted as "I prefer audio/basic, but send me any audio |  | SHOULD be interpreted as "I prefer audio/basic, but send me any audio |
| type if it is the best available after an 80% mark-down in quality." |  | type if it is the best available after an 80% mark-down in quality." |
| If no Accept header field is present, then it is assumed that the |  | If no Accept header field is present, then it is assumed that the |
| client accepts all media types. If an Accept header field is |  | client accepts all media types. If an Accept header field is |
| present, and if the server cannot send a response which is acceptable |  | present, and if the server cannot send a response which is acceptable |
| according to the combined Accept field value, then the server SHOULD |  | according to the combined Accept field value, then the server SHOULD |
| send a 406 (not acceptable) response. |  | send a 406 (Not Acceptable) response. |
| A more elaborate example is |  | A more elaborate example is |
| Accept: text/plain; q=0.5, text/html, |  | Accept: text/plain; q=0.5, text/html, |
| text/x-dvi; q=0.8, text/x-c |  | text/x-dvi; q=0.8, text/x-c |
| Verbally, this would be interpreted as "text/html and text/x-c are |  | Verbally, this would be interpreted as "text/html and text/x-c are |
| the preferred media types, but if they do not exist, then send the |  | the preferred media types, but if they do not exist, then send the |
| text/x-dvi 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." |
| skipping to change at page 17, line 46 |  | skipping to change at page 18, line 34 |
| 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 |
| 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. |
| 5.3. Accept-Encoding |  | 5.3. Accept-Encoding |
| The Accept-Encoding request-header field is similar to Accept, but |  | The Accept-Encoding request-header field is similar to Accept, but |
| restricts the content-codings (Section 2.2) that are acceptable in |  | restricts the content-codings (Section 2.2) that are acceptable in |
| the response. |  | the response. |
| Accept-Encoding = "Accept-Encoding" ":" |  | Accept-Encoding = "Accept-Encoding" ":" |
| 1#( codings [ ";" "q" "=" qvalue ] ) |  | #( codings [ ";" "q" "=" qvalue ] ) |
| codings = ( content-coding | "*" ) |  | codings = ( content-coding | "*" ) |
| Examples of its use are: |  | Examples of its use are: |
| Accept-Encoding: compress, gzip |  | Accept-Encoding: compress, gzip |
| Accept-Encoding: |  | Accept-Encoding: |
| Accept-Encoding: * |  | Accept-Encoding: * |
| 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 |
| skipping to change at page 22, line 37 |  | skipping to change at page 23, line 24 |
| 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 |  | URI 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 [Part6]. |  | retrieved from a single requested resource, as described in Section 7 |
|  |  | 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-URI. |
| 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. |
| 5.8. Content-MD5 |  | 5.8. Content-MD5 |
| The Content-MD5 entity-header field, as defined in RFC 1864 |  | The Content-MD5 entity-header field, as defined in [RFC1864], is an |
| [RFC1864], is an MD5 digest of the entity-body for the purpose of |  | MD5 digest of the entity-body for the purpose of providing an end-to- |
| providing an end-to-end message integrity check (MIC) of the entity- |  | end message integrity check (MIC) of the entity-body. (Note: a MIC |
| body. (Note: a MIC is good for detecting accidental modification of |  | is good for detecting accidental modification of the entity-body in |
| the entity-body in transit, but is not proof against malicious |  | transit, but is not proof against malicious attacks.) |
| attacks.) |  |  |
| Content-MD5 = "Content-MD5" ":" md5-digest |  | Content-MD5 = "Content-MD5" ":" md5-digest |
| md5-digest = <base64 of 128 bit MD5 digest as per RFC 1864> |  | md5-digest = <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. |
| The MD5 digest is computed based on the content of the entity-body, |  | The MD5 digest is computed based on the content of the entity-body, |
| skipping to change at page 25, line 27 |  | skipping to change at page 26, line 16 |
| 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. |
| 7.2. Content-Disposition Issues |  | 7.2. Content-Disposition Issues |
| RFC 1806 [RFC1806], from which the often implemented Content- |  | [RFC1806], from which the often implemented Content-Disposition (see |
| Disposition (see Appendix B.1) header in HTTP is derived, has a |  | Appendix B.1) header in HTTP is derived, has a number of very serious |
| number of very serious security considerations. Content-Disposition |  | security considerations. Content-Disposition is not part of the HTTP |
| is not part of the HTTP standard, but since it is widely implemented, |  | standard, but since it is widely implemented, we are documenting its |
| we are documenting its use and risks for implementors. See RFC 2183 |  | use and risks for implementors. See [RFC2183] (which updates |
| [RFC2183] (which updates RFC 1806) for details. |  | [RFC1806]) for details. |
| 8. Acknowledgments |  | 8. Acknowledgments |
| Based on an XML translation of RFC 2616 by Julian Reschke. |  |  |
| 9. References |  | 9. References |
|  |  | 9.1. Normative References |
|  |  | [ISO-8859-1] |
|  |  | International Organization for Standardization, |
|  |  | "Information technology -- 8-bit single-byte coded graphic |
|  |  | character sets -- Part 1: Latin alphabet No. 1", ISO/ |
|  |  | 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., and T. Berners-Lee, "HTTP/1.1, |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| part 1: URIs, Connections, and Message Parsing", |  | and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, |
| draft-ietf-httpbis-p1-messaging-00 (work in progress), |  | and Message Parsing", draft-ietf-httpbis-p1-messaging-01 |
| December 2007. |  | (work in progress), January 2008. |
| [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., and T. Berners-Lee, "HTTP/1.1, |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| part 2: Message Semantics", |  | and J. Reschke, Ed., "HTTP/1.1, part 2: Message |
| draft-ietf-httpbis-p2-semantics-00 (work in progress), |  | Semantics", draft-ietf-httpbis-p2-semantics-01 (work in |
| December 2007. |  | progress), January 2008. |
| [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., and T. Berners-Lee, "HTTP/1.1, |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| part 4: Conditional Requests", |  | and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional |
| draft-ietf-httpbis-p4-conditional-00 (work in progress), |  | Requests", draft-ietf-httpbis-p4-conditional-01 (work in |
| December 2007. |  | progress), January 2008. |
| [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., and T. Berners-Lee, "HTTP/1.1, |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| part 5: Range Requests and Partial Responses", |  | and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and |
| draft-ietf-httpbis-p5-range-00 (work in progress), |  | Partial Responses", draft-ietf-httpbis-p5-range-01 (work |
| December 2007. |  | in progress), January 2008. |
| [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., and T. Berners-Lee, "HTTP/1.1, |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| part 6: Caching", draft-ietf-httpbis-p6-cache-00 (work in |  | and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", |
| progress), December 2007. |  | draft-ietf-httpbis-p6-cache-01 (work in progress), |
|  |  | January 2008. |
| [RFC1590] Postel, J., "Media Type Registration Procedure", RFC 1590, |  |  |
| November 1996. |  |  |
| [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, |  |  |
| RFC 1700, October 1994. |  |  |
| [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. |
| [RFC1806] Troost, R. and S. Dorner, "Communicating Presentation |  |  |
| Information in Internet Messages: The Content-Disposition |  |  |
| Header", RFC 1806, June 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. |
| [RFC1867] Masinter, L. and E. Nebel, "Form-based File Upload in |  |  |
| HTML", RFC 1867, November 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. |
|  |  | RFC1950 is an Informational RFC, thus it may be less |
|  |  | stable than this specification. On the other hand, this |
|  |  | downward reference was present since [RFC2068] (published |
|  |  | in 1997), therefore it is unlikely to cause problems in |
|  |  | practice. |
| [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification |  | [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification |
| version 1.3", RFC 1951, May 1996. |  | version 1.3", RFC 1951, May 1996. |
|  |  | RFC1951 is an Informational RFC, thus it may be less |
|  |  | stable than this specification. On the other hand, this |
|  |  | downward reference was present since [RFC2068] (published |
|  |  | in 1997), therefore it is unlikely to cause problems in |
|  |  | practice. |
| [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G. |  | [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G. |
| Randers-Pehrson, "GZIP file format specification version |  | Randers-Pehrson, "GZIP file format specification version |
| 4.3", RFC 1952, May 1996. |  | 4.3", RFC 1952, May 1996. |
|  |  | RFC1952 is an Informational RFC, thus it may be less |
|  |  | stable than this specification. On the other hand, this |
|  |  | downward reference was present since [RFC2068] (published |
|  |  | in 1997), therefore it is unlikely to cause problems in |
|  |  | practice. |
| [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail |  | [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail |
| Extensions (MIME) Part One: Format of Internet Message |  | Extensions (MIME) Part One: Format of Internet Message |
| Bodies", RFC 2045, November 1996. |  | Bodies", RFC 2045, November 1996. |
| [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail |  | [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail |
| Extensions (MIME) Part Two: Media Types", RFC 2046, |  | Extensions (MIME) Part Two: Media Types", RFC 2046, |
| November 1996. |  | November 1996. |
|  |  | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |
|  |  | Requirement Levels", BCP 14, RFC 2119, March 1997. |
|  |  | [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and |
|  |  | Registration Procedures", BCP 13, RFC 4288, December 2005. |
|  |  | 9.2. Informative References |
|  |  | [RFC1806] Troost, R. and S. Dorner, "Communicating Presentation |
|  |  | Information in Internet Messages: The Content-Disposition |
|  |  | Header", RFC 1806, June 1995. |
|  |  | [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext |
|  |  | 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 |
| Examples", RFC 2049, November 1996. |  | Examples", RFC 2049, November 1996. |
| [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. |  | [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. |
| Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", |  | Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", |
| RFC 2068, January 1997. |  | RFC 2068, January 1997. |
| [RFC2076] Palme, J., "Common Internet Message Headers", RFC 2076, |  | [RFC2076] Palme, J., "Common Internet Message Headers", RFC 2076, |
| February 1997. |  | February 1997. |
| [RFC2110] Palme, J. and A. Hopmann, "MIME E-mail Encapsulation of |  |  |
| Aggregate Documents, such as HTML (MHTML)", RFC 2110, |  |  |
| March 1997. |  |  |
| [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating |  | [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating |
| Presentation Information in Internet Messages: The |  | Presentation Information in Internet Messages: The |
| Content-Disposition Header Field", RFC 2183, August 1997. |  | Content-Disposition Header Field", RFC 2183, August 1997. |
| [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and |  | [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and |
| Languages", BCP 18, RFC 2277, January 1998. |  | Languages", BCP 18, RFC 2277, January 1998. |
| [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO |  | [RFC2388] Masinter, L., "Returning Values from Forms: multipart/ |
| 10646", RFC 2279, January 1998. |  | form-data", RFC 2388, August 1998. |
|  |  | [RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud, |
|  |  | "MIME Encapsulation of Aggregate Documents, such as HTML |
|  |  | (MHTML)", RFC 2557, March 1999. |
| [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., |  | [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext |  | Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext |
| Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. |  | Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. |
| [RFC822] Crocker, D., "Standard for the format of ARPA Internet |  | [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, |
| text messages", STD 11, RFC 822, August 1982. |  | April 2001. |
|  |  | [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO |
|  |  | 10646", RFC 3629, STD 63, November 2003. |
| Appendix A. Differences Between HTTP Entities and RFC 2045 Entities |  | Appendix A. Differences Between HTTP Entities and RFC 2045 Entities |
| HTTP/1.1 uses many of the constructs defined for Internet Mail (RFC |  | HTTP/1.1 uses many of the constructs defined for Internet Mail |
| 822 [RFC822]) and the Multipurpose Internet Mail Extensions (MIME |  | ([RFC2822]) and the Multipurpose Internet Mail Extensions (MIME |
| [RFC2045]) to allow entities to be transmitted in an open variety of |  | [RFC2045]) to allow entities to be transmitted in an open variety of |
| representations and with extensible mechanisms. However, RFC 2045 |  | representations and with extensible mechanisms. However, RFC 2045 |
| discusses mail, and HTTP has a few features that are different from |  | discusses mail, and HTTP has a few features that are different from |
| those described in RFC 2045. These differences were carefully chosen |  | those described in RFC 2045. These differences were carefully chosen |
| to optimize performance over binary connections, to allow greater |  | to optimize performance over binary connections, to allow greater |
| freedom in the use of new media types, to make date comparisons |  | freedom in the use of new media types, to make date comparisons |
| easier, and to acknowledge the practice of some early HTTP servers |  | easier, and to acknowledge the practice of some early HTTP servers |
| and clients. |  | and clients. |
| This appendix describes specific areas where HTTP differs from RFC |  | This appendix describes specific areas where HTTP differs from RFC |
| skipping to change at page 28, line 23 |  | skipping to change at page 29, line 41 |
| where necessary. Proxies and gateways from MIME environments to HTTP |  | where necessary. Proxies and gateways from MIME environments to HTTP |
| also need to be aware of the differences because some conversions |  | also need to be aware of the differences because some conversions |
| might be required. |  | might be required. |
| A.1. MIME-Version |  | A.1. MIME-Version |
| HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages |  | HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages |
| MAY include a single MIME-Version general-header field to indicate |  | MAY include a single MIME-Version general-header field to indicate |
| what version of the MIME protocol was used to construct the message. |  | what version of the MIME protocol was used to construct the message. |
| Use of the MIME-Version header field indicates that the message is in |  | Use of the MIME-Version header field indicates that the message is in |
| full compliance with the MIME protocol (as defined in RFC |  | full compliance with the MIME protocol (as defined in [RFC2045]). |
| 2045[RFC2045]). Proxies/gateways are responsible for ensuring full |  | Proxies/gateways are responsible for ensuring full compliance (where |
| compliance (where possible) when exporting HTTP messages to strict |  | possible) when exporting HTTP messages to strict MIME environments. |
| MIME environments. |  |  |
| MIME-Version = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT |  | MIME-Version = "MIME-Version" ":" 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 |
| RFC 2045 [RFC2045] requires that an Internet mail entity be converted |  | [RFC2045] requires that an Internet mail entity be converted to |
| to canonical form prior to being transferred, as described in section |  | canonical form prior to being transferred, as described in Section 4 |
| 4 of RFC 2049 [RFC2049]. Section 2.3.1 of this document describes |  | of [RFC2049]. Section 2.3.1 of this document describes the forms |
| the forms allowed for subtypes of the "text" media type when |  | allowed for subtypes of the "text" media type when transmitted over |
| transmitted over HTTP. RFC 2046 requires that content with a type of |  | HTTP. [RFC2046] requires that content with a type of "text" |
| "text" represent line breaks as CRLF and forbids the use of CR or LF |  | represent line breaks as CRLF and forbids the use of CR or LF outside |
| outside of line break sequences. HTTP allows CRLF, bare CR, and bare |  | of line break sequences. HTTP allows CRLF, bare CR, and bare LF to |
| 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 2.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. |
| skipping to change at page 29, line 26 |  | skipping to change at page 30, line 45 |
| 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.4. No Content-Transfer-Encoding |
| HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC |  | HTTP does not use the Content-Transfer-Encoding field of RFC 2045. |
| 2045. Proxies and gateways from MIME-compliant protocols to HTTP |  | Proxies and gateways from MIME-compliant protocols to HTTP MUST |
| MUST remove any non-identity CTE ("quoted-printable" or "base64") |  | remove any Content-Transfer-Encoding prior to delivering the response |
| 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.5. 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.6. MHTML and Line Length Limitations |
| HTTP implementations which share code with MHTML [RFC2110] |  | 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 2.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 |
| RFC 1945 and RFC 2068 document protocol elements used by some |  | [RFC1945] and [RFC2068] document protocol elements used by some |
| existing HTTP implementations, but not consistently and correctly |  | existing HTTP implementations, but not consistently and correctly |
| across most HTTP/1.1 applications. Implementors are advised to be |  | across most HTTP/1.1 applications. Implementors are advised to be |
| aware of these features, but cannot rely upon their presence in, or |  | aware of these features, but cannot rely upon their presence in, or |
| interoperability with, other HTTP/1.1 applications. Some of these |  | interoperability with, other HTTP/1.1 applications. Some of these |
| describe proposed experimental features, and some describe features |  | describe proposed experimental features, and some describe features |
| that experimental deployment found lacking that are now addressed in |  | that experimental deployment found lacking that are now addressed in |
| the base HTTP/1.1 specification. |  | the base HTTP/1.1 specification. |
| A number of other headers, such as Content-Disposition and Title, |  | A number of other headers, such as Content-Disposition and Title, |
| from SMTP and MIME are also often implemented (see RFC 2076 |  | from SMTP and MIME are also often implemented (see [RFC2076]). |
| [RFC2076]). |  |  |
| B.1. Content-Disposition |  | B.1. Content-Disposition |
| The Content-Disposition response-header field has been proposed as a |  | The Content-Disposition response-header field has been proposed as a |
| means for the origin server to suggest a default filename if the user |  | means for the origin server to suggest a default filename if the user |
| requests that the content is saved to a file. This usage is derived |  | requests that the content is saved to a file. This usage is derived |
| from the definition of Content-Disposition in RFC 1806 [RFC1806]. |  | from the definition of Content-Disposition in [RFC1806]. |
| content-disposition = "Content-Disposition" ":" |  | content-disposition = "Content-Disposition" ":" |
| disposition-type *( ";" disposition-parm ) |  | disposition-type *( ";" disposition-parm ) |
| disposition-type = "attachment" | disp-extension-token |  | disposition-type = "attachment" | disp-extension-token |
| disposition-parm = filename-parm | disp-extension-parm |  | disposition-parm = filename-parm | disp-extension-parm |
| filename-parm = "filename" "=" quoted-string |  | filename-parm = "filename" "=" quoted-string |
| disp-extension-token = token |  | disp-extension-token = token |
| disp-extension-parm = token "=" ( token | quoted-string ) |  | disp-extension-parm = token "=" ( token | quoted-string ) |
| An example is |  | An example is |
| skipping to change at page 31, line 7 |  | skipping to change at page 32, line 29 |
| 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 7.2 for Content-Disposition security issues. |  | See Section 7.2 for Content-Disposition security issues. |
| Appendix C. Changes from RFC 2068 |  | Appendix C. Compatibility with Previous Versions |
|  |  | C.1. Changes from RFC 2068 |
|  |  | Transfer-coding and message lengths all interact in ways that |
|  |  | required fixing exactly when chunked encoding is used (to allow for |
|  |  | transfer encoding that may not be self delimiting); it was important |
|  |  | to straighten out exactly how message lengths are computed. |
|  |  | (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 5.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 [RFC2110]. |  | 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 2.2) |  | discovered in caching. (Section 2.2) |
| Quality Values of zero should indicate that "I don't want something" |  | Quality Values of zero should indicate that "I don't want something" |
| to allow clients to refuse a representation. (Section 2.4) |  | to allow clients to refuse a representation. (Section 2.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 RFC 2068 [RFC2068]. |  | specification, but not commonly implemented. See [RFC2068]. |
|  |  | C.2. Changes from RFC 2616 |
|  |  | Clarify contexts that charset is used in. (Section 2.1) |
|  |  | Remove reference to non-existant identity transfer-coding value |
|  |  | tokens. (Appendix A.4) |
|  |  | Appendix D. Change Log (to be removed by RFC Editor before publication) |
|  |  | D.1. Since RFC2616 |
|  |  | Extracted relevant partitions from [RFC2616]. |
|  |  | D.2. Since draft-ietf-httpbis-p3-payload-00 |
|  |  | Closed issues: |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/8>: "Media Type |
|  |  | Registrations" (<http://purl.org/NET/http-errata#media-reg>) |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/14>: |
|  |  | "Clarification regarding quoting of charset values" |
|  |  | (<http://purl.org/NET/http-errata#charactersets>) |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/16>: "Remove |
|  |  | 'identity' token references" |
|  |  | (<http://purl.org/NET/http-errata#identity>) |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/25>: "Accept- |
|  |  | Encoding BNF" |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative |
|  |  | and Informative references" |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/46>: "RFC1700 |
|  |  | references" |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/65>: |
|  |  | "Informative references" |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/66>: |
|  |  | "ISO-8859-1 Reference" |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/68>: "Encoding |
|  |  | References Normative" |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/86>: "Normative |
|  |  | up-to-date references" |
| Index |  | Index |
| A |  | A |
| Accept header 15 |  | Accept header 16 |
| Accept-Charset header 17 |  | Accept-Charset header 18 |
| Accept-Encoding header 17 |  | Accept-Encoding header 18 |
| Accept-Language header 19 |  | Accept-Language header 20 |
| Alternates header 31 |  | Alternates header 33 |
| C |  | C |
| compress 6 |  | compress 7 |
| Content-Base header 31 |  | Content-Base header 33 |
| Content-Disposition header 30 |  | Content-Disposition header 31 |
| Content-Encoding header 20 |  | Content-Encoding header 21 |
| Content-Language header 21 |  | Content-Language header 22 |
| Content-Location header 22 |  | Content-Location header 22 |
| Content-MD5 header 22 |  | Content-MD5 header 23 |
| Content-Type header 24 |  | Content-Type header 24 |
| Content-Version header 31 |  | Content-Version header 33 |
| D |  | D |
| deflate 7 |  | deflate 7 |
| Derived-From header 31 |  | Derived-From header 33 |
| G |  | G |
| Grammar |  | Grammar |
| Accept 15 |  | Accept 16 |
| Accept-Charset 17 |  | Accept-Charset 18 |
| Accept-Encoding 18 |  | Accept-Encoding 18 |
| accept-extension 15 |  | accept-extension 16 |
| Accept-Language 19 |  | Accept-Language 20 |
| accept-params 15 |  | accept-params 16 |
| attribute 7 |  | attribute 8 |
| charset 5 |  | charset 6 |
| codings 18 |  | codings 18 |
| content-coding 6 |  | content-coding 7 |
| content-disposition 30 |  | content-disposition 32 |
| Content-Encoding 20 |  | Content-Encoding 21 |
| Content-Language 21 |  | Content-Language 22 |
| Content-Location 22 |  | Content-Location 23 |
| Content-MD5 23 |  | Content-MD5 23 |
| Content-Type 24 |  | Content-Type 24 |
| disp-extension-parm 30 |  | disp-extension-parm 32 |
| disp-extension-token 30 |  | disp-extension-token 32 |
| disposition-parm 30 |  | disposition-parm 32 |
| disposition-type 30 |  | disposition-type 32 |
| entity-body 11 |  | entity-body 12 |
| entity-header 11 |  | entity-header 11 |
| extension-header 11 |  | extension-header 11 |
| filename-parm 30 |  | filename-parm 32 |
| language-range 19 |  | language-range 20 |
| language-tag 10 |  | language-tag 11 |
| md5-digest 23 |  | md5-digest 23 |
| media-range 15 |  | media-range 16 |
| media-type 7 |  | media-type 8 |
| MIME-Version 28 |  | MIME-Version 29 |
| parameter 7 |  | parameter 8 |
| primary-tag 10 |  | primary-tag 11 |
| qvalue 9 |  | qvalue 10 |
| subtag 10 |  | subtag 11 |
| subtype 7 |  | subtype 8 |
| type 7 |  | type 8 |
| value 7 |  | value 8 |
| gzip 6 |  | gzip 7 |
| H |  | H |
| Headers |  | Headers |
| Accept 15 |  | Accept 16 |
| Accept-Charset 17 |  | Accept-Charset 18 |
| Accept-Encoding 17 |  | Accept-Encoding 18 |
| Accept-Language 19 |  | Accept-Language 20 |
| Alternate 31 |  | Alternate 33 |
| Content-Base 31 |  | Content-Base 33 |
| Content-Disposition 30 |  | Content-Disposition 31 |
| Content-Encoding 20 |  | Content-Encoding 21 |
| Content-Language 21 |  | Content-Language 22 |
| Content-Location 22 |  | Content-Location 22 |
| Content-MD5 22 |  | Content-MD5 23 |
| Content-Type 24 |  | Content-Type 24 |
| Content-Version 31 |  | Content-Version 33 |
| Derived-From 31 |  | Derived-From 33 |
| Link 31 |  | Link 33 |
| Public 31 |  | Public 33 |
| URI 31 |  | URI 33 |
| I |  | I |
| identity 7 |  | identity 8 |
| L |  | L |
| Link header 31 |  | Link header 33 |
| P |  | P |
| Public header 31 |  | Public header 33 |
| U |  | U |
| URI header 31 |  | URI header 33 |
| Authors' Addresses |  | Authors' Addresses |
| Roy T. Fielding (editor) |  | Roy T. Fielding (editor) |
| Day Software |  | Day Software |
| 23 Corporate Plaza DR, Suite 280 |  | 23 Corporate Plaza DR, Suite 280 |
| Newport Beach, CA 92660 |  | Newport Beach, CA 92660 |
| USA |  | USA |
| Phone: +1-949-706-5300 |  | Phone: +1-949-706-5300 |
| skipping to change at page 36, line 4 |  | skipping to change at page 38, line 4 |
| Tim Berners-Lee |  | Tim Berners-Lee |
| World Wide Web Consortium |  | World Wide Web Consortium |
| MIT Computer Science and Artificial Intelligence Laboratory |  | MIT Computer Science and Artificial Intelligence Laboratory |
| The Stata Center, Building 32 |  | The Stata Center, Building 32 |
| 32 Vassar Street |  | 32 Vassar Street |
| Cambridge, MA 02139 |  | Cambridge, MA 02139 |
| USA |  | USA |
| Email: timbl@w3.org |  | Email: timbl@w3.org |
| URI: http://www.w3.org/People/Berners-Lee/ |  | URI: http://www.w3.org/People/Berners-Lee/ |
|  |  | Yves Lafon (editor) |
|  |  | World Wide Web Consortium |
|  |  | W3C / ERCIM |
|  |  | 2004, rte des Lucioles |
|  |  | Sophia-Antipolis, AM 06902 |
|  |  | France |
|  |  | Email: ylafon@w3.org |
|  |  | URI: http://www.raubacapeu.net/people/yves/ |
|  |  | Julian F. Reschke (editor) |
|  |  | greenbytes GmbH |
|  |  | Hafenweg 16 |
|  |  | Muenster, NW 48155 |
|  |  | Germany |
|  |  | Phone: +49 251 2807760 |
|  |  | Fax: +49 251 2807761 |
|  |  | Email: julian.reschke@greenbytes.de |
|  |  | URI: http://greenbytes.de/tech/webdav/ |
| Full Copyright Statement |  | Full Copyright Statement |
| Copyright (C) The IETF Trust (2007). |  | Copyright (C) The IETF Trust (2008). |
| This document is subject to the rights, licenses and restrictions |  | This document is subject to the rights, licenses and restrictions |
| contained in BCP 78, and except as set forth therein, the authors |  | contained in BCP 78, and except as set forth therein, the authors |
| retain all their rights. |  | retain all their rights. |
| This document and the information contained herein are provided on an |  | This document and the information contained herein are provided on an |
| "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS |  | "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS |
| OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND |  | OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND |
| THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS |  | THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS |
| OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF |  | OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF |
End of changes. 89 change blocks.
| 245 lines changed or deleted |  | 387 lines changed or added |
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/