| draft-ietf-httpbis-p3-payload-04.txt |  | draft-ietf-httpbis-p3-payload-05.txt |
--- | --- | --- | --- | ---
| Network Working Group R. Fielding, Ed. |  | Network 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: March 2, 2009 J. Mogul |  | Expires: May 20, 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 |
| August 29, 2008 |  | November 16, 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-04 |  | draft-ietf-httpbis-p3-payload-05 |
| 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 49 |  | 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 March 2, 2009. |  | This Internet-Draft will expire on May 20, 2009. |
| 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://www.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://www.tools.ietf.org/wg/httpbis/>. |  | <http://tools.ietf.org/wg/httpbis/>. |
| The changes in this draft are summarized in Appendix D.4. |  | The changes in this draft are summarized in Appendix D.6. |
| 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 |  | 2. Notational Conventions and Generic Grammar . . . . . . . . . . 5 |
| 3. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 6 |  | 3. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 6 |
| 3.1. Character Sets . . . . . . . . . . . . . . . . . . . . . . 6 |  | 3.1. Character Sets . . . . . . . . . . . . . . . . . . . . . . 6 |
| 3.1.1. Missing Charset . . . . . . . . . . . . . . . . . . . 7 |  | 3.1.1. Missing Charset . . . . . . . . . . . . . . . . . . . 7 |
| 3.2. Content Codings . . . . . . . . . . . . . . . . . . . . . 7 |  | 3.2. Content Codings . . . . . . . . . . . . . . . . . . . . . 7 |
| skipping to change at page 3, line 34 |  | skipping to change at page 3, line 34 |
| 5. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 13 |  | 5. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 13 |
| 5.1. Server-driven Negotiation . . . . . . . . . . . . . . . . 14 |  | 5.1. Server-driven Negotiation . . . . . . . . . . . . . . . . 14 |
| 5.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . . 15 |  | 5.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . . 15 |
| 5.3. Transparent Negotiation . . . . . . . . . . . . . . . . . 16 |  | 5.3. Transparent Negotiation . . . . . . . . . . . . . . . . . 16 |
| 6. Header Field Definitions . . . . . . . . . . . . . . . . . . . 16 |  | 6. Header Field Definitions . . . . . . . . . . . . . . . . . . . 16 |
| 6.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . . 16 |  | 6.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . . 16 |
| 6.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . . 18 |  | 6.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . . 18 |
| 6.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 19 |  | 6.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 19 |
| 6.4. Accept-Language . . . . . . . . . . . . . . . . . . . . . 20 |  | 6.4. Accept-Language . . . . . . . . . . . . . . . . . . . . . 20 |
| 6.5. Content-Encoding . . . . . . . . . . . . . . . . . . . . . 22 |  | 6.5. Content-Encoding . . . . . . . . . . . . . . . . . . . . . 22 |
| 6.6. Content-Language . . . . . . . . . . . . . . . . . . . . . 22 |  | 6.6. Content-Language . . . . . . . . . . . . . . . . . . . . . 23 |
| 6.7. Content-Location . . . . . . . . . . . . . . . . . . . . . 23 |  | 6.7. Content-Location . . . . . . . . . . . . . . . . . . . . . 24 |
| 6.8. Content-MD5 . . . . . . . . . . . . . . . . . . . . . . . 24 |  | 6.8. Content-MD5 . . . . . . . . . . . . . . . . . . . . . . . 24 |
| 6.9. Content-Type . . . . . . . . . . . . . . . . . . . . . . . 25 |  | 6.9. Content-Type . . . . . . . . . . . . . . . . . . . . . . . 26 |
| 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 |  | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 |
| 7.1. Message Header Registration . . . . . . . . . . . . . . . 26 |  | 7.1. Message Header Registration . . . . . . . . . . . . . . . 26 |
| 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26 |  | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 27 |
| 8.1. Privacy Issues Connected to Accept Headers . . . . . . . . 26 |  | 8.1. Privacy Issues Connected to Accept Headers . . . . . . . . 27 |
| 8.2. Content-Disposition Issues . . . . . . . . . . . . . . . . 27 |  | 8.2. Content-Disposition Issues . . . . . . . . . . . . . . . . 28 |
| 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 |  | 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 |
| 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 |  | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 |
| 10.1. Normative References . . . . . . . . . . . . . . . . . . . 27 |  | 10.1. Normative References . . . . . . . . . . . . . . . . . . . 28 |
| 10.2. Informative References . . . . . . . . . . . . . . . . . . 29 |  | 10.2. Informative References . . . . . . . . . . . . . . . . . . 30 |
| Appendix A. Differences Between HTTP Entities and RFC 2045 |  | Appendix A. Differences Between HTTP Entities and RFC 2045 |
| Entities . . . . . . . . . . . . . . . . . . . . . . 30 |  | Entities . . . . . . . . . . . . . . . . . . . . . . 31 |
| A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 31 |  | A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 31 |
| A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 31 |  | A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 32 |
| A.3. Introduction of Content-Encoding . . . . . . . . . . . . . 32 |  | A.3. Introduction of Content-Encoding . . . . . . . . . . . . . 32 |
| A.4. No Content-Transfer-Encoding . . . . . . . . . . . . . . . 32 |  | A.4. No Content-Transfer-Encoding . . . . . . . . . . . . . . . 32 |
| A.5. Introduction of Transfer-Encoding . . . . . . . . . . . . 32 |  | A.5. Introduction of Transfer-Encoding . . . . . . . . . . . . 33 |
| A.6. MHTML and Line Length Limitations . . . . . . . . . . . . 32 |  | A.6. MHTML and Line Length Limitations . . . . . . . . . . . . 33 |
| Appendix B. Additional Features . . . . . . . . . . . . . . . . . 32 |  | Appendix B. Additional Features . . . . . . . . . . . . . . . . . 33 |
| B.1. Content-Disposition . . . . . . . . . . . . . . . . . . . 33 |  | B.1. Content-Disposition . . . . . . . . . . . . . . . . . . . 33 |
| Appendix C. Compatibility with Previous Versions . . . . . . . . 33 |  | 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 . . . . . . . . . . . . . . . . . . 34 |  | C.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 35 |
| Appendix D. Change Log (to be removed by RFC Editor before |  | Appendix D. Change Log (to be removed by RFC Editor before |
| publication) . . . . . . . . . . . . . . . . . . . . 34 |  | publication) . . . . . . . . . . . . . . . . . . . . 35 |
| D.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 34 |  | D.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 35 |
| D.2. Since draft-ietf-httpbis-p3-payload-00 . . . . . . . . . . 34 |  | D.2. Since draft-ietf-httpbis-p3-payload-00 . . . . . . . . . . 35 |
| D.3. Since draft-ietf-httpbis-p3-payload-01 . . . . . . . . . . 35 |  | D.3. Since draft-ietf-httpbis-p3-payload-01 . . . . . . . . . . 36 |
| D.4. Since draft-ietf-httpbis-p3-payload-02 . . . . . . . . . . 35 |  | D.4. Since draft-ietf-httpbis-p3-payload-02 . . . . . . . . . . 36 |
| D.5. Since draft-ietf-httpbis-p3-payload-03 . . . . . . . . . . 36 |  | D.5. Since draft-ietf-httpbis-p3-payload-03 . . . . . . . . . . 36 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 |  | D.6. Since draft-ietf-httpbis-p3-payload-04 . . . . . . . . . . 37 |
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 |
| Intellectual Property and Copyright Statements . . . . . . . . . . 42 |  | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 |
|  |  | Intellectual Property and Copyright Statements . . . . . . . . . . 43 |
| 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 43 |  | skipping to change at page 5, line 43 |
| 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 |  | 2. Notational Conventions and Generic Grammar |
| This specification uses the ABNF syntax defined in Section 2.1 of |  | This specification uses the ABNF syntax defined in Section 2.1 of |
| [Part1] and the core rules defined in Section 2.2 of [Part1]: |  | [Part1] and the core rules defined in Section 2.2 of [Part1]: |
| [[abnf.dep: ABNF syntax and basic rules will be adopted from RFC |  |  |
| 5234, see <http://tools.ietf.org/wg/httpbis/trac/ticket/36>.]] |  |  |
| ALPHA = <ALPHA, defined in [Part1], Section 2.2> |  | ALPHA = <ALPHA, defined in [Part1], Section 2.2> |
| DIGIT = <DIGIT, defined in [Part1], Section 2.2> |  | DIGIT = <DIGIT, defined in [Part1], Section 2.2> |
| OCTET = <OCTET, defined in [Part1], Section 2.2> |  | OCTET = <OCTET, defined in [Part1], Section 2.2> |
| quoted-string = <quoted-string, defined in [Part1], Section 2.2> |  | quoted-string = <quoted-string, defined in [Part1], Section 2.2> |
| token = <token, 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: |
| absoluteURI = <absoluteURI, defined in [Part1], Section 3.2.1> |  | absolute-URI = <absolute-URI, defined in [Part1], Section 3.2> |
| 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.1> |  | 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> |
| Last-Modified = <Last-Modified, defined in [Part4], Section 7.6> |  | Last-Modified = <Last-Modified, defined in [Part4], Section 7.6> |
| Content-Range = <Content-Range, defined in [Part5], Section 6.2> |  | Content-Range = <Content-Range, defined in [Part5], Section 6.2> |
| Expires = <Expires, defined in [Part6], Section 16.3> |  | Expires = <Expires, defined in [Part6], Section 16.3> |
| 3. Protocol Parameters |  | 3. Protocol Parameters |
| skipping to change at page 9, line 6 |  | skipping to change at page 9, line 5 |
| 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 |  | 3.3. Media Types |
| HTTP uses Internet Media Types [RFC2046] in the Content-Type |  | HTTP uses Internet Media Types [RFC2046] in the Content-Type |
| (Section 6.9) and Accept (Section 6.1) header fields in order to |  | (Section 6.9) and Accept (Section 6.1) header fields in order to |
| provide open and extensible data typing and type negotiation. |  | provide open and extensible data typing and type negotiation. |
| media-type = type "/" subtype *( ";" 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 |
| attribute = token |  | attribute = token |
| value = token | quoted-string |  | value = token / quoted-string |
| The type, subtype, and parameter attribute names are case- |  | The type, subtype, and parameter attribute names are case- |
| insensitive. Parameter values might or might not be case-sensitive, |  | insensitive. Parameter values might or might not be case-sensitive, |
| depending on the semantics of the parameter name. Linear white space |  | depending on the semantics of the parameter name. The presence or |
| (LWS) MUST NOT be used between the type and subtype, nor between an |  | absence of a parameter might be significant to the processing of a |
| attribute and its value. The presence or absence of a parameter |  | media-type, depending on its definition within the media type |
| might be significant to the processing of a media-type, depending on |  | registry. |
| its definition within the media type registry. |  |  |
| A parameter value that matches the token production may be |  | A parameter value that matches the token production may be |
| transmitted as either a token or within a quoted-string. The quoted |  | transmitted as either a token or within a quoted-string. The quoted |
| and unquoted values are equivalent. |  | and unquoted values are equivalent. |
| 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. |
| skipping to change at page 11, line 22 |  | skipping to change at page 11, line 18 |
| 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 |
| decimal point. User configuration of these values SHOULD also be |  | decimal point. User configuration of these values SHOULD also be |
| limited in this fashion. |  | limited in this fashion. |
| qvalue = ( "0" [ "." 0*3DIGIT ] ) |  | qvalue = ( "0" [ "." 0*3DIGIT ] ) |
| | ( "1" [ "." 0*3("0") ] ) |  | / ( "1" [ "." 0*3("0") ] ) |
| "Quality values" is a misnomer, since these values merely represent |  | "Quality values" is a misnomer, since these values merely represent |
| relative degradation in desired quality. |  | relative degradation in desired quality. |
| 3.5. Language Tags |  | 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- |
| skipping to change at page 12, line 22 |  | skipping to change at page 12, line 21 |
| 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 |  | 4.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 6.5 |
| | Content-Language ; Section 6.6 |  | / Content-Language ; Section 6.6 |
| | Content-Length ; [Part1], Section 8.2 |  | / Content-Length ; [Part1], Section 8.2 |
| | Content-Location ; Section 6.7 |  | / Content-Location ; Section 6.7 |
| | Content-MD5 ; Section 6.8 |  | / Content-MD5 ; Section 6.8 |
| | Content-Range ; [Part5], Section 6.2 |  | / Content-Range ; [Part5], Section 6.2 |
| | Content-Type ; Section 6.9 |  | / Content-Type ; Section 6.9 |
| | Expires ; [Part6], Section 16.3 |  | / Expires ; [Part6], Section 16.3 |
| | Last-Modified ; [Part4], Section 7.6 |  | / Last-Modified ; [Part4], Section 7.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 |  | 4.2. Entity Body |
| skipping to change at page 16, line 36 |  | skipping to change at page 16, line 36 |
| 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 |  | 6.1. Accept |
| The Accept request-header field can be used to specify certain media |  | The request-header field "Accept" can be used to specify certain |
| types which are acceptable for the response. Accept headers can be |  | media types which are acceptable for the response. Accept headers |
| used to indicate that the request is specifically limited to a small |  | can be used to indicate that the request is specifically limited to a |
| set of desired types, as in the case of a request for an in-line |  | small set of desired types, as in the case of a request for an in- |
| image. |  | line image. |
| Accept = "Accept" ":" |  | Accept = "Accept" ":" OWS Accept-v |
| #( media-range [ accept-params ] ) |  | Accept-v = #( media-range [ accept-params ] ) |
| media-range = ( "*/*" |  | media-range = ( "*/*" |
| | ( type "/" "*" ) |  | / ( type "/" "*" ) |
| | ( type "/" subtype ) |  | / ( type "/" subtype ) |
| ) *( ";" parameter ) |  | ) *( OWS ";" OWS parameter ) |
| accept-params = ";" "q" "=" qvalue *( accept-extension ) |  | accept-params = OWS ";" OWS "q=" qvalue *( accept-ext ) |
| accept-extension = ";" token [ "=" ( token | quoted-string ) ] |  | accept-ext = OWS ";" OWS token |
|  |  | [ "=" ( token / quoted-string ) ] |
| 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 |
| skipping to change at page 18, line 36 |  | skipping to change at page 18, line 36 |
| text/html;level=2 = 0.4 |  | text/html;level=2 = 0.4 |
| text/html;level=3 = 0.7 |  | 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 |  | 6.2. Accept-Charset |
| The Accept-Charset request-header field can be used to indicate what |  | The request-header field "Accept-Charset" can be used to indicate |
| character sets are acceptable for the response. This field allows |  | what character sets are acceptable for the response. This field |
| clients capable of understanding more comprehensive or special- |  | allows clients capable of understanding more comprehensive or |
| purpose character sets to signal that capability to a server which is |  | special-purpose character sets to signal that capability to a server |
| capable of representing documents in those character sets. |  | which is capable of representing documents in those character sets. |
| Accept-Charset = "Accept-Charset" ":" |  | Accept-Charset = "Accept-Charset" ":" OWS |
| 1#( ( charset | "*" ) [ ";" "q" "=" qvalue ] ) |  | Accept-Charset-v |
|  |  | Accept-Charset-v = 1#( ( charset / "*" ) |
|  |  | [ OWS ";" OWS "q=" qvalue ] ) |
| Character set values are described in Section 3.1. Each charset MAY |  | Character set values are described in Section 3.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 |
| 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 |
| skipping to change at page 19, line 20 |  | skipping to change at page 19, line 22 |
| 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 |  | 6.3. Accept-Encoding |
| The Accept-Encoding request-header field 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 3.2) that are acceptable in |
| the response. |  | the response. |
| Accept-Encoding = "Accept-Encoding" ":" |  | Accept-Encoding = "Accept-Encoding" ":" OWS |
| #( codings [ ";" "q" "=" qvalue ] ) |  | Accept-Encoding-v |
| codings = ( content-coding | "*" ) |  | Accept-Encoding-v = |
|  |  | #( codings [ OWS ";" OWS "q=" qvalue ] ) |
|  |  | codings = ( content-coding / "*" ) |
| Each codings value MAY be given an associated quality value which |  | Each codings value MAY be given an associated quality value which |
| represents the preference for that encoding. The default value is |  | represents the preference for that encoding. The default value is |
| q=1. |  | q=1. |
| Examples of its use are: |  | Examples of its use are: |
| Accept-Encoding: compress, gzip |  | Accept-Encoding: compress, gzip |
| Accept-Encoding: |  | Accept-Encoding: |
| Accept-Encoding: * |  | Accept-Encoding: * |
| skipping to change at page 20, line 41 |  | skipping to change at page 20, line 44 |
| 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 |  | 6.4. Accept-Language |
| The Accept-Language request-header field 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 3.5. |
| Accept-Language = "Accept-Language" ":" |  | Accept-Language = "Accept-Language" ":" OWS |
| 1#( language-range [ ";" "q" "=" qvalue ] ) |  | Accept-Language-v |
|  |  | Accept-Language-v = |
|  |  | 1#( language-range [ OWS ";" OWS "q=" qvalue ] ) |
| language-range = |  | language-range = |
| <language-range, defined in [RFC4647], Section 2.1> |  | <language-range, defined in [RFC4647], Section 2.1> |
| Each language-range can be given an associated quality value which |  | Each language-range can be given an associated quality value which |
| represents an estimate of the user's preference for the languages |  | represents an estimate of the user's preference for the languages |
| specified by that range. The quality value defaults to "q=1". For |  | specified by that range. The quality value defaults to "q=1". For |
| example, |  | example, |
| Accept-Language: da, en-gb;q=0.8, en;q=0.7 |  | Accept-Language: da, en-gb;q=0.8, en;q=0.7 |
| skipping to change at page 22, line 13 |  | skipping to change at page 22, line 23 |
| 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 |  | 6.5. Content-Encoding |
| The Content-Encoding entity-header field is used as a modifier to the |  | The entity-header field "Content-Encoding" is used as a modifier to |
| 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" ":" 1#content-coding |  | Content-Encoding = "Content-Encoding" ":" OWS Content-Encoding-v |
|  |  | 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 3.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-URI. 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 |
| skipping to change at page 22, line 49 |  | skipping to change at page 23, line 12 |
| 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 |  | 6.6. Content-Language |
| The Content-Language entity-header field 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" ":" 1#language-tag |  | Content-Language = "Content-Language" ":" OWS Content-Language-v |
|  |  | Content-Language-v = 1#language-tag |
| Language tags are defined in Section 3.5. The primary purpose of |  | Language tags are defined in Section 3.5. 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 |
| skipping to change at page 23, line 40 |  | skipping to change at page 24, line 7 |
| 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 |  | 6.7. Content-Location |
| The Content-Location entity-header field 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" ":" |  | Content-Location = "Content-Location" ":" OWS |
| ( absoluteURI | relativeURI ) |  | Content-Location-v |
|  |  | Content-Location-v = |
|  |  | absolute-URI / relativeURI |
| 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 |  | URI if the desire is to identify the source of that particular |
| entity. |  | entity. |
| skipping to change at page 24, line 29 |  | skipping to change at page 24, line 47 |
| of [Part6]. |  | 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. |
| 6.8. Content-MD5 |  | 6.8. Content-MD5 |
| The Content-MD5 entity-header field, 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" ":" md5-digest |  | Content-MD5-v = <base64 of 128 bit MD5 digest as per [RFC1864]> |
| 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 43 |  | skipping to change at page 26, line 11 |
| 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 |  | 6.9. Content-Type |
| The Content-Type entity-header field indicates the media type of the |  | The entity-header field "Content-Type" indicates the media type of |
| entity-body sent to the recipient or, in the case of the HEAD method, |  | the entity-body sent to the recipient or, in the case of the HEAD |
| the media type that would have been sent had the request been a GET. |  | method, the media type that would have been sent had the request been |
|  |  | a GET. |
| Content-Type = "Content-Type" ":" media-type |  | Content-Type = "Content-Type" ":" OWS Content-Type-v |
|  |  | 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 3.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 4.2.1. |
| 7. IANA Considerations |  | 7. IANA Considerations |
| 7.1. Message Header Registration |  | 7.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]): |
| skipping to change at page 28, line 9 |  | skipping to change at page 28, line 29 |
| [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-04 |  | and Message Parsing", draft-ietf-httpbis-p1-messaging-05 |
| (work in progress), August 2008. |  | (work in progress), November 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., 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-04 (work in |  | Semantics", draft-ietf-httpbis-p2-semantics-05 (work in |
| progress), August 2008. |  | progress), November 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., 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-04 (work in |  | Requests", draft-ietf-httpbis-p4-conditional-05 (work in |
| progress), August 2008. |  | progress), November 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., 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-04 (work |  | Partial Responses", draft-ietf-httpbis-p5-range-05 (work |
| in progress), August 2008. |  | in progress), November 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., 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-04 (work in progress), |  | draft-ietf-httpbis-p6-cache-05 (work in progress), |
| August 2008. |  | November 2008. |
| [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 26 |  | skipping to change at page 30, line 47 |
| form-data", RFC 2388, August 1998. |  | form-data", RFC 2388, August 1998. |
| [RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud, |  | [RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud, |
| "MIME Encapsulation of Aggregate Documents, such as HTML |  | "MIME Encapsulation of Aggregate Documents, such as HTML |
| (MHTML)", RFC 2557, March 1999. |  | (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. |
| [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, |  |  |
| April 2001. |  |  |
| [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO |  | [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO |
| 10646", RFC 3629, STD 63, November 2003. |  | 10646", RFC 3629, STD 63, November 2003. |
| [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration |  | [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration |
| Procedures for Message Header Fields", BCP 90, RFC 3864, |  | Procedures for Message Header Fields", BCP 90, RFC 3864, |
| September 2004. |  | September 2004. |
| [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and |  | [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and |
| Registration Procedures", BCP 13, RFC 4288, December 2005. |  | Registration Procedures", BCP 13, RFC 4288, December 2005. |
|  |  | [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, |
|  |  | October 2008. |
| 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 |  | HTTP/1.1 uses many of the constructs defined for Internet Mail |
| ([RFC2822]) and the Multipurpose Internet Mail Extensions (MIME |  | ([RFC5322]) 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 31, line 22 |  | skipping to change at page 31, line 42 |
| 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 [RFC2045]). |  | full compliance with the MIME protocol (as defined in [RFC2045]). |
| Proxies/gateways are responsible for ensuring full compliance (where |  | Proxies/gateways are responsible for ensuring full compliance (where |
| possible) when exporting HTTP messages to strict MIME environments. |  | possible) when exporting HTTP messages to strict MIME environments. |
| MIME-Version = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT |  | MIME-Version = "MIME-Version" ":" OWS MIME-Version-v |
|  |  | 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 3.3.1 of this document describes the forms |
| skipping to change at page 33, line 22 |  | skipping to change at page 34, line 5 |
| 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 [RFC2076]). |  | from SMTP and MIME are also often implemented (see [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 [RFC2183]. |  | from the definition of Content-Disposition in [RFC2183]. |
| content-disposition = "Content-Disposition" ":" |  | content-disposition = "Content-Disposition" ":" OWS |
| disposition-type *( ";" disposition-parm ) |  | content-disposition-v |
| disposition-type = "attachment" | disp-extension-token |  | content-disposition-v = disposition-type |
| disposition-parm = filename-parm | disp-extension-parm |  | *( OWS ";" OWS disposition-parm ) |
|  |  | disposition-type = "attachment" / disp-extension-token |
|  |  | 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 |
| Content-Disposition: attachment; filename="fname.ext" |  | Content-Disposition: attachment; filename="fname.ext" |
| 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. |
| skipping to change at page 34, line 49 |  | skipping to change at page 35, line 29 |
| Appendix D. Change Log (to be removed by RFC Editor before publication) |  | Appendix D. Change Log (to be removed by RFC Editor before publication) |
| D.1. Since RFC2616 |  | D.1. Since RFC2616 |
| Extracted relevant partitions from [RFC2616]. |  | Extracted relevant partitions from [RFC2616]. |
| D.2. Since draft-ietf-httpbis-p3-payload-00 |  | D.2. Since draft-ietf-httpbis-p3-payload-00 |
| Closed issues: |  | Closed issues: |
| o <http://www3.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://www3.tools.ietf.org/wg/httpbis/trac/ticket/14>: |  |  |
| "Clarification regarding quoting of charset values" |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/14>: "Clarification |
|  |  | regarding quoting of charset values" |
| (<http://purl.org/NET/http-errata#charactersets>) |  | (<http://purl.org/NET/http-errata#charactersets>) |
| o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/16>: "Remove |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/16>: "Remove |
| 'identity' token references" |  | 'identity' token references" |
| (<http://purl.org/NET/http-errata#identity>) |  | (<http://purl.org/NET/http-errata#identity>) |
| o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/25>: "Accept- |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/25>: "Accept- |
| Encoding BNF" |  | Encoding BNF" |
| o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and |
| and Informative references" |  | Informative references" |
| o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/46>: "RFC1700 |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/46>: "RFC1700 |
| references" |  | references" |
| o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/55>: "Updating |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/55>: "Updating to |
| to RFC4288" |  | RFC4288" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/65>: "Informative |
| o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/65>: |  | references" |
| "Informative references" |  |  |
| o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/66>: |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/66>: "ISO-8859-1 |
| "ISO-8859-1 Reference" |  | Reference" |
| o <http://www3.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://www3.tools.ietf.org/wg/httpbis/trac/ticket/86>: "Normative |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/86>: "Normative up- |
| up-to-date references" |  | to-date references" |
| D.3. Since draft-ietf-httpbis-p3-payload-01 |  | D.3. Since draft-ietf-httpbis-p3-payload-01 |
| Ongoing work on ABNF conversion |  | Ongoing work on ABNF conversion |
| (<http://www3.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 |  | D.4. Since draft-ietf-httpbis-p3-payload-02 |
| Closed issues: |  | Closed issues: |
| o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/67>: "Quoting |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/67>: "Quoting |
| Charsets" |  | Charsets" |
| o <http://www3.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://www3.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://www3.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 |  | D.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" |
| skipping to change at page 36, line 25 |  | skipping to change at page 37, line 4 |
| D.5. Since draft-ietf-httpbis-p3-payload-03 |  | D.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 |
|  |  | Closed issues: |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/132>: "RFC 2822 is |
|  |  | updated by RFC 5322" |
|  |  | Ongoing work on ABNF conversion |
|  |  | (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |
|  |  | o Use "/" instead of "|" for alternatives. |
|  |  | o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional |
|  |  | whitespace ("OWS") and required whitespace ("RWS"). |
|  |  | o Rewrite ABNFs to spell out whitespace rules, factor out header |
|  |  | value format definitions. |
| 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 34 |  | Alternates header 35 |
| C |  | C |
| compress 8 |  | compress 8 |
| Content-Base header 34 |  | Content-Base header 35 |
| Content-Disposition header 33 |  | Content-Disposition header 33 |
| Content-Encoding header 22 |  | Content-Encoding header 22 |
| Content-Language header 22 |  | Content-Language header 23 |
| Content-Location header 23 |  | Content-Location header 24 |
| Content-MD5 header 24 |  | Content-MD5 header 24 |
| Content-Type header 25 |  | Content-Type header 26 |
| Content-Version header 34 |  | Content-Version header 35 |
| D |  | D |
| deflate 8 |  | deflate 8 |
| Derived-From header 34 |  | Derived-From header 35 |
| G |  | G |
| Grammar |  | Grammar |
| Accept 16 |  | Accept 16 |
| Accept-Charset 18 |  | Accept-Charset 18 |
|  |  | Accept-Charset-v 18 |
| Accept-Encoding 19 |  | Accept-Encoding 19 |
| accept-extension 16 |  | Accept-Encoding-v 19 |
| Accept-Language 20 |  | accept-ext 16 |
|  |  | Accept-Language 21 |
|  |  | Accept-Language-v 21 |
| accept-params 16 |  | accept-params 16 |
|  |  | Accept-v 16 |
| attribute 9 |  | attribute 9 |
| charset 7 |  | charset 6 |
| codings 19 |  | codings 19 |
| content-coding 7 |  | content-coding 7 |
| content-disposition 33 |  | content-disposition 34 |
|  |  | content-disposition-v 34 |
| Content-Encoding 22 |  | Content-Encoding 22 |
|  |  | Content-Encoding-v 22 |
| Content-Language 23 |  | Content-Language 23 |
| Content-Location 23 |  | Content-Language-v 23 |
| Content-MD5 24 |  | Content-Location 24 |
| Content-Type 25 |  | Content-Location-v 24 |
| disp-extension-parm 33 |  | Content-MD5 25 |
| disp-extension-token 33 |  | Content-MD5-v 25 |
| disposition-parm 33 |  | Content-Type 26 |
| disposition-type 33 |  | Content-Type-v 26 |
|  |  | disp-extension-parm 34 |
|  |  | disp-extension-token 34 |
|  |  | disposition-parm 34 |
|  |  | disposition-type 34 |
| entity-body 12 |  | entity-body 12 |
| entity-header 12 |  | entity-header 12 |
| extension-header 12 |  | extension-header 12 |
| filename-parm 33 |  | filename-parm 34 |
| language-range 20 |  | language-range 21 |
| language-tag 11 |  | language-tag 11 |
| md5-digest 24 |  |  |
| media-range 16 |  | media-range 16 |
| media-type 9 |  | media-type 9 |
| MIME-Version 31 |  | MIME-Version 31 |
|  |  | MIME-Version-v 31 |
| parameter 9 |  | parameter 9 |
| primary-tag 11 |  | primary-tag 11 |
| qvalue 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 34 |  | Alternate 35 |
| Content-Base 34 |  | Content-Base 35 |
| Content-Disposition 33 |  | Content-Disposition 33 |
| Content-Encoding 22 |  | Content-Encoding 22 |
| Content-Language 22 |  | Content-Language 23 |
| Content-Location 23 |  | Content-Location 24 |
| Content-MD5 24 |  | Content-MD5 24 |
| Content-Type 25 |  | Content-Type 26 |
| Content-Version 34 |  | Content-Version 35 |
| Derived-From 34 |  | Derived-From 35 |
| Link 34 |  | Link 35 |
| MIME-Version 31 |  | MIME-Version 31 |
| Public 34 |  | Public 35 |
| URI 34 |  | URI 35 |
| I |  | I |
| identity 8 |  | identity 8 |
| L |  | L |
| Link header 34 |  | Link header 35 |
| M |  | M |
| MIME-Version header 31 |  | MIME-Version header 31 |
| P |  | P |
| Public header 34 |  | Public header 35 |
| U |  | U |
| URI header 34 |  | URI header 35 |
| 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 |
End of changes. 99 change blocks.
| 176 lines changed or deleted |  | 219 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/