| draft-ietf-httpbis-p1-messaging-02.txt |  | draft-ietf-httpbis-p1-messaging-03.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: August 27, 2008 J. Mogul |  | Expires: December 19, 2008 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 |
| February 24, 2008 |  | June 17, 2008 |
| HTTP/1.1, part 1: URIs, Connections, and Message Parsing |  | HTTP/1.1, part 1: URIs, Connections, and Message Parsing |
| draft-ietf-httpbis-p1-messaging-02 |  | draft-ietf-httpbis-p1-messaging-03 |
| 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 August 27, 2008. |  | This Internet-Draft will expire on December 19, 2008. |
| Copyright Notice |  |  |
| 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 1 of the |  | information initiative since 1990. This document is Part 1 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 1 provides |  | "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides |
| an overview of HTTP and its associated terminology, defines the |  | an overview of HTTP and its associated terminology, defines the |
| skipping to change at page 2, line 30 |  | skipping to change at page 2, line 26 |
| frames, and describes general security concerns for implementations. |  | frames, and describes general security concerns for implementations. |
| 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://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://www.tools.ietf.org/wg/httpbis/>. |  | <http://www.tools.ietf.org/wg/httpbis/>. |
| This draft incorporates those issue resolutions that were either |  | The changes in this draft are summarized in Appendix E.4. |
| 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. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 5 |  | 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 5 |
| 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 |  | 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 |
| 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 |  | 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 |
| 1.4. Overall Operation . . . . . . . . . . . . . . . . . . . . 9 |  | 1.4. Overall Operation . . . . . . . . . . . . . . . . . . . . 9 |
| 2. Notational Conventions and Generic Grammar . . . . . . . . . . 11 |  | 2. Notational Conventions and Generic Grammar . . . . . . . . . . 11 |
| 2.1. Augmented BNF . . . . . . . . . . . . . . . . . . . . . . 11 |  | 2.1. Augmented BNF . . . . . . . . . . . . . . . . . . . . . . 11 |
| skipping to change at page 4, line 16 |  | skipping to change at page 4, line 16 |
| 8.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 40 |  | 8.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 40 |
| 8.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 |  | 8.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 |
| 8.3.1. Clockless Origin Server Operation . . . . . . . . . . 42 |  | 8.3.1. Clockless Origin Server Operation . . . . . . . . . . 42 |
| 8.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 |  | 8.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 |
| 8.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 |  | 8.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 |
| 8.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 44 |  | 8.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 44 |
| 8.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 44 |  | 8.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 44 |
| 8.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 45 |  | 8.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 45 |
| 8.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 |  | 8.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 |
| 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 |  | 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 |
| 10. Security Considerations . . . . . . . . . . . . . . . . . . . 47 |  | 9.1. Message Header Registration . . . . . . . . . . . . . . . 47 |
|  |  | 10. Security Considerations . . . . . . . . . . . . . . . . . . . 48 |
| 10.1. Personal Information . . . . . . . . . . . . . . . . . . . 48 |  | 10.1. Personal Information . . . . . . . . . . . . . . . . . . . 48 |
| 10.2. Abuse of Server Log Information . . . . . . . . . . . . . 48 |  | 10.2. Abuse of Server Log Information . . . . . . . . . . . . . 48 |
| 10.3. Attacks Based On File and Path Names . . . . . . . . . . . 48 |  | 10.3. Attacks Based On File and Path Names . . . . . . . . . . . 49 |
| 10.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 49 |  | 10.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 49 |
| 10.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 49 |  | 10.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 50 |
| 10.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 50 |  | 10.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 50 |
| 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50 |  | 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50 |
| 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51 |  | 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52 |
| 12.1. Normative References . . . . . . . . . . . . . . . . . . . 51 |  | 12.1. Normative References . . . . . . . . . . . . . . . . . . . 52 |
| 12.2. Informative References . . . . . . . . . . . . . . . . . . 52 |  | 12.2. Informative References . . . . . . . . . . . . . . . . . . 53 |
| Appendix A. Internet Media Types . . . . . . . . . . . . . . . . 54 |  | Appendix A. Internet Media Types . . . . . . . . . . . . . . . . 55 |
| A.1. Internet Media Type message/http . . . . . . . . . . . . . 54 |  | A.1. Internet Media Type message/http . . . . . . . . . . . . . 55 |
| A.2. Internet Media Type application/http . . . . . . . . . . . 56 |  | A.2. Internet Media Type application/http . . . . . . . . . . . 56 |
| Appendix B. Tolerant Applications . . . . . . . . . . . . . . . . 57 |  | Appendix B. Tolerant Applications . . . . . . . . . . . . . . . . 57 |
| Appendix C. Conversion of Date Formats . . . . . . . . . . . . . 58 |  | Appendix C. Conversion of Date Formats . . . . . . . . . . . . . 58 |
| Appendix D. Compatibility with Previous Versions . . . . . . . . 58 |  | Appendix D. Compatibility with Previous Versions . . . . . . . . 58 |
| D.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 58 |  | D.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 59 |
| D.1.1. Changes to Simplify Multi-homed Web Servers and |  | D.1.1. Changes to Simplify Multi-homed Web Servers and |
| Conserve IP Addresses . . . . . . . . . . . . . . . . 59 |  | Conserve IP Addresses . . . . . . . . . . . . . . . . 59 |
| D.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 59 |  | D.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 60 |
| D.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 60 |  | D.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 60 |
| D.4. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 60 |  | D.4. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 61 |
| Appendix E. Change Log (to be removed by RFC Editor before |  | Appendix E. Change Log (to be removed by RFC Editor before |
| publication) . . . . . . . . . . . . . . . . . . . . 61 |  | publication) . . . . . . . . . . . . . . . . . . . . 61 |
| E.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 61 |  | E.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 61 |
| E.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 61 |  | E.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 61 |
| E.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 62 |  | E.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 63 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 |  | E.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 64 |
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 67 |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 |
| Intellectual Property and Copyright Statements . . . . . . . . . . 70 |  | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 68 |
|  |  | Intellectual Property and Copyright Statements . . . . . . . . . . 71 |
| 1. Introduction |  | 1. Introduction |
| 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. The first version of HTTP, |  | information initiative since 1990. The first version of HTTP, |
| commonly referred to as HTTP/0.9, was a simple protocol for raw data |  | commonly referred to as HTTP/0.9, was a simple protocol for raw data |
| transfer across the Internet with only a single method and no |  | transfer across the Internet with only a single method and no |
| metadata. HTTP/1.0, as defined by [RFC1945], improved the protocol |  | metadata. HTTP/1.0, as defined by [RFC1945], improved the protocol |
| skipping to change at page 15, line 46 |  | skipping to change at page 15, line 46 |
| A string of text is parsed as a single word if it is quoted using |  | A string of text is parsed as a single word if it is quoted using |
| double-quote marks. |  | double-quote marks. |
| quoted-string = ( DQUOTE *(qdtext | quoted-pair ) DQUOTE ) |  | quoted-string = ( DQUOTE *(qdtext | quoted-pair ) DQUOTE ) |
| qdtext = <any TEXT excluding DQUOTE and "\"> |  | qdtext = <any TEXT excluding DQUOTE and "\"> |
| The backslash character ("\") MAY be used as a single-character |  | The backslash character ("\") MAY be used as a single-character |
| quoting mechanism only within quoted-string and comment constructs. |  | quoting mechanism only within quoted-string and comment constructs. |
| quoted-pair = "\" CHAR |  | quoted-text = %x01-09 | |
|  |  | %x0B-0C | |
|  |  | %x0E-FF ; Characters excluding NUL, CR and LF |
|  |  | quoted-pair = "\" quoted-text |
| 2.3. ABNF Rules defined in other Parts of the Specification |  | 2.3. ABNF Rules defined in other Parts of the Specification |
| The ABNF rules below are defined in other parts: |  | The ABNF rules below are defined in other parts: |
| request-header = <request-header, defined in [Part2], Section 4> |  | request-header = <request-header, defined in [Part2], Section 4> |
| response-header = <response-header, defined in [Part2], Section 6> |  | response-header = <response-header, defined in [Part2], Section 6> |
| accept-params = <accept-params, defined in [Part3], Section 6.1> |  | accept-params = <accept-params, defined in [Part3], Section 6.1> |
| entity-body = <entity-body, defined in [Part3], Section 4.2> |  | entity-body = <entity-body, defined in [Part3], Section 4.2> |
| skipping to change at page 16, line 41 |  | skipping to change at page 16, line 41 |
| The <minor> number is incremented when the changes made to the |  | The <minor> number is incremented when the changes made to the |
| protocol add features which do not change the general message parsing |  | protocol add features which do not change the general message parsing |
| algorithm, but which may add to the message semantics and imply |  | algorithm, but which may add to the message semantics and imply |
| additional capabilities of the sender. The <major> number is |  | additional capabilities of the sender. The <major> number is |
| incremented when the format of a message within the protocol is |  | incremented when the format of a message within the protocol is |
| changed. See [RFC2145] for a fuller explanation. |  | changed. See [RFC2145] for a fuller explanation. |
| The version of an HTTP message is indicated by an HTTP-Version field |  | The version of an HTTP message is indicated by an HTTP-Version field |
| in the first line of the message. HTTP-Version is case-sensitive. |  | in the first line of the message. HTTP-Version is case-sensitive. |
| HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT |  | HTTP-Version = HTTP-Prot-Name "/" 1*DIGIT "." 1*DIGIT |
|  |  | HTTP-Prot-Name = %x48.54.54.50 ; "HTTP", case-sensitive |
| Note that the major and minor numbers MUST be treated as separate |  | Note that the major and minor numbers MUST be treated as separate |
| integers and that each MAY be incremented higher than a single digit. |  | integers and that each MAY be incremented higher than a single digit. |
| Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is |  | Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is |
| lower than HTTP/12.3. Leading zeros MUST be ignored by recipients |  | lower than HTTP/12.3. Leading zeros MUST be ignored by recipients |
| and MUST NOT be sent. |  | and MUST NOT be sent. |
| An application that sends a request or response message that includes |  | An application that sends a request or response message that includes |
| HTTP-Version of "HTTP/1.1" MUST be at least conditionally compliant |  | HTTP-Version of "HTTP/1.1" MUST be at least conditionally compliant |
| with this specification. Applications that are at least |  | with this specification. Applications that are at least |
| skipping to change at page 20, line 8 |  | skipping to change at page 20, line 10 |
| All HTTP date/time stamps MUST be represented in Greenwich Mean Time |  | All HTTP date/time stamps MUST be represented in Greenwich Mean Time |
| (GMT), without exception. For the purposes of HTTP, GMT is exactly |  | (GMT), without exception. For the purposes of HTTP, GMT is exactly |
| equal to UTC (Coordinated Universal Time). This is indicated in the |  | equal to UTC (Coordinated Universal Time). This is indicated in the |
| first two formats by the inclusion of "GMT" as the three-letter |  | first two formats by the inclusion of "GMT" as the three-letter |
| abbreviation for time zone, and MUST be assumed when reading the |  | abbreviation for time zone, and MUST be assumed when reading the |
| asctime format. HTTP-date is case sensitive and MUST NOT include |  | asctime format. HTTP-date is case sensitive and MUST NOT include |
| additional LWS beyond that specifically included as SP in the |  | additional LWS beyond that specifically included as SP in the |
| grammar. |  | grammar. |
| HTTP-date = rfc1123-date | rfc850-date | asctime-date |  | HTTP-date = rfc1123-date | obsolete-date |
|  |  | obsolete-date = rfc850-date | asctime-date |
| rfc1123-date = wkday "," SP date1 SP time SP "GMT" |  | rfc1123-date = wkday "," SP date1 SP time SP "GMT" |
| rfc850-date = weekday "," SP date2 SP time SP "GMT" |  | rfc850-date = weekday "," SP date2 SP time SP "GMT" |
| asctime-date = wkday SP date3 SP time SP 4DIGIT |  | asctime-date = wkday SP date3 SP time SP 4DIGIT |
| date1 = 2DIGIT SP month SP 4DIGIT |  | date1 = 2DIGIT SP month SP 4DIGIT |
| ; day month year (e.g., 02 Jun 1982) |  | ; day month year (e.g., 02 Jun 1982) |
| date2 = 2DIGIT "-" month "-" 2DIGIT |  | date2 = 2DIGIT "-" month "-" 2DIGIT |
| ; day-month-year (e.g., 02-Jun-82) |  | ; day-month-year (e.g., 02-Jun-82) |
| date3 = month SP ( 2DIGIT | ( SP 1DIGIT )) |  | date3 = month SP ( 2DIGIT | ( SP 1DIGIT )) |
| ; month day (e.g., Jun 2) |  | ; month day (e.g., Jun 2) |
| time = 2DIGIT ":" 2DIGIT ":" 2DIGIT |  | time = 2DIGIT ":" 2DIGIT ":" 2DIGIT |
| skipping to change at page 46, line 22 |  | skipping to change at page 46, line 22 |
| version rules of Section 3.1 and future updates to this |  | version rules of Section 3.1 and future updates to this |
| specification. Any token can be used as a protocol name; however, it |  | specification. Any token can be used as a protocol name; however, it |
| will only be useful if both the client and server associate the name |  | will only be useful if both the client and server associate the name |
| with the same protocol. |  | with the same protocol. |
| 8.9. Via |  | 8.9. Via |
| The Via general-header field MUST be used by gateways and proxies to |  | The Via general-header field MUST be used by gateways and proxies to |
| indicate the intermediate protocols and recipients between the user |  | indicate the intermediate protocols and recipients between the user |
| agent and the server on requests, and between the origin server and |  | agent and the server on requests, and between the origin server and |
| the client on responses. It is analogous to the "Received" field of |  | the client on responses. It is analogous to the "Received" field |
| [RFC2822] and is intended to be used for tracking message forwards, |  | defined in Section 3.6.7 of [RFC2822] and is intended to be used for |
| avoiding request loops, and identifying the protocol capabilities of |  | tracking message forwards, avoiding request loops, and identifying |
| all senders along the request/response chain. |  | the protocol capabilities of all senders along the request/response |
|  |  | chain. |
| Via = "Via" ":" 1#( received-protocol received-by [ comment ] ) |  | Via = "Via" ":" 1#( received-protocol received-by [ comment ] ) |
| received-protocol = [ protocol-name "/" ] protocol-version |  | received-protocol = [ protocol-name "/" ] protocol-version |
| protocol-name = token |  | protocol-name = token |
| protocol-version = token |  | protocol-version = token |
| received-by = ( uri-host [ ":" port ] ) | pseudonym |  | received-by = ( uri-host [ ":" port ] ) | pseudonym |
| pseudonym = token |  | pseudonym = token |
| The received-protocol indicates the protocol version of the message |  | The received-protocol indicates the protocol version of the message |
| received by the server or client along each segment of the request/ |  | received by the server or client along each segment of the request/ |
| skipping to change at page 47, line 45 |  | skipping to change at page 47, line 46 |
| Via: 1.0 ricky, 1.1 mertz, 1.0 lucy |  | Via: 1.0 ricky, 1.1 mertz, 1.0 lucy |
| Applications SHOULD NOT combine multiple entries unless they are all |  | Applications SHOULD NOT combine multiple entries unless they are all |
| under the same organizational control and the hosts have already been |  | under the same organizational control and the hosts have already been |
| replaced by pseudonyms. Applications MUST NOT combine entries which |  | replaced by pseudonyms. Applications MUST NOT combine entries which |
| have different received-protocol values. |  | have different received-protocol values. |
| 9. IANA Considerations |  | 9. IANA Considerations |
| [[anchor1: TBD.]] |  | 9.1. Message Header Registration |
|  |  | The Message Header Registry located at <http://www.iana.org/ |
|  |  | assignments/message-headers/message-header-index.html> should be |
|  |  | updated with the permanent registrations below (see [RFC3864]): |
|  |  | +-------------------+----------+----------+-------------+ |
|  |  | | Header Field Name | Protocol | Status | Reference | |
|  |  | +-------------------+----------+----------+-------------+ |
|  |  | | Connection | http | standard | Section 8.1 | |
|  |  | | Content-Length | http | standard | Section 8.2 | |
|  |  | | Date | http | standard | Section 8.3 | |
|  |  | | Host | http | standard | Section 8.4 | |
|  |  | | TE | http | standard | Section 8.5 | |
|  |  | | Trailer | http | standard | Section 8.6 | |
|  |  | | Transfer-Encoding | http | standard | Section 8.7 | |
|  |  | | Upgrade | http | standard | Section 8.8 | |
|  |  | | Via | http | standard | Section 8.9 | |
|  |  | +-------------------+----------+----------+-------------+ |
|  |  | The change controller is: "IETF (iesg@ietf.org) - Internet |
|  |  | Engineering Task Force". |
| 10. Security Considerations |  | 10. Security Considerations |
| This section is meant to inform application developers, information |  | This section is meant to inform application developers, information |
| providers, and users of the security limitations in HTTP/1.1 as |  | providers, and users of the security limitations in HTTP/1.1 as |
| described by this document. The discussion does not include |  | described by this document. The discussion does not include |
| definitive solutions to the problems revealed, though it does make |  | definitive solutions to the problems revealed, though it does make |
| some suggestions for reducing security risks. |  | some suggestions for reducing security risks. |
| 10.1. Personal Information |  | 10.1. Personal Information |
| skipping to change at page 51, line 43 |  | skipping to change at page 52, line 16 |
| [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. |
| [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-02 (work in |  | Semantics", draft-ietf-httpbis-p2-semantics-03 (work in |
| progress), February 2008. |  | progress), June 2008. |
| [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part3] 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 3: Message Payload |  | and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload |
| and Content Negotiation", draft-ietf-httpbis-p3-payload-02 |  | and Content Negotiation", draft-ietf-httpbis-p3-payload-03 |
| (work in progress), February 2008. |  | (work in progress), June 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-02 (work |  | Partial Responses", draft-ietf-httpbis-p5-range-03 (work |
| in progress), February 2008. |  | in progress), June 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-02 (work in progress), |  | draft-ietf-httpbis-p6-cache-03 (work in progress), |
| February 2008. |  | June 2008. |
| [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. |
| [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) |  | [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) |
| Part Three: Message Header Extensions for Non-ASCII Text", |  | Part Three: Message Header Extensions for Non-ASCII Text", |
| RFC 2047, November 1996. |  | RFC 2047, November 1996. |
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |  | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |
| skipping to change at page 54, line 13 |  | skipping to change at page 54, line 35 |
| [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. |
| [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, |  | [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, |
| April 2001. |  | April 2001. |
| [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, |  | [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, |
| April 2001. |  | April 2001. |
|  |  | [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration |
|  |  | Procedures for Message Header Fields", BCP 90, RFC 3864, |
|  |  | September 2004. |
| [RFC3977] Feather, C., "Network News Transfer Protocol (NNTP)", |  | [RFC3977] Feather, C., "Network News Transfer Protocol (NNTP)", |
| RFC 3977, October 2006. |  | RFC 3977, October 2006. |
| [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. |
| [RFC822] Crocker, D., "Standard for the format of ARPA Internet |  | [RFC822] Crocker, D., "Standard for the format of ARPA Internet |
| text messages", STD 11, RFC 822, August 1982. |  | text messages", STD 11, RFC 822, August 1982. |
| [RFC959] Postel, J. and J. Reynolds, "File Transfer Protocol", |  | [RFC959] Postel, J. and J. Reynolds, "File Transfer Protocol", |
| skipping to change at page 60, line 48 |  | skipping to change at page 61, line 23 |
| codings), a new header field (TE) and enabling trailer headers in the |  | codings), a new header field (TE) and enabling trailer headers in the |
| future. Transfer encoding is a major performance benefit, so it was |  | future. Transfer encoding is a major performance benefit, so it was |
| worth fixing [Nie1997]. TE also solves another, obscure, downward |  | worth fixing [Nie1997]. TE also solves another, obscure, downward |
| interoperability problem that could have occurred due to interactions |  | interoperability problem that could have occurred due to interactions |
| between authentication trailers, chunked encoding and HTTP/1.0 |  | between authentication trailers, chunked encoding and HTTP/1.0 |
| clients.(Section 3.4, 3.4.1, and 8.5) |  | clients.(Section 3.4, 3.4.1, and 8.5) |
| D.4. Changes from RFC 2616 |  | D.4. Changes from RFC 2616 |
| The CHAR rule does not allow the NUL character anymore (this affects |  | The CHAR rule does not allow the NUL character anymore (this affects |
| the comment and quoted-string rules). (Section 2.2) |  | the comment and quoted-string rules). Furthermore, the quoted-pair |
|  |  | rule does not allow escaping NUL, CR or LF anymore. (Section 2.2) |
| Clarify that HTTP-Version is case sensitive. (Section 3.1) |  | Clarify that HTTP-Version is case sensitive. (Section 3.1) |
| Remove reference to non-existant identity transfer-coding value |  | Remove reference to non-existant identity transfer-coding value |
| tokens. (Sections 3.4 and 4.4) |  | tokens. (Sections 3.4 and 4.4) |
| Clarification that the chunk length does not include the count of the |  | Clarification that the chunk length does not include the count of the |
| octets in the chunk header and trailer. (Section 3.4.1) |  | octets in the chunk header and trailer. (Section 3.4.1) |
| Fix BNF to add query, as the abs_path production in Section 3 of |  | Fix BNF to add query, as the abs_path production in Section 3 of |
| [RFC2396] doesn't define it. (Section 5.1.2) |  | [RFC2396] doesn't define it. (Section 5.1.2) |
| Clarify exactly when close connection options must be sent. |  | Clarify exactly when close connection options must be sent. |
| skipping to change at page 63, line 43 |  | skipping to change at page 64, line 22 |
| o Move "Product Tokens" section (back) into Part 1, as "token" is |  | o Move "Product Tokens" section (back) into Part 1, as "token" is |
| used in the definition of the Upgrade header. |  | used in the definition of the Upgrade header. |
| 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. |
| o Rewrite prose rule "token" in terms of "tchar", rewrite prose rule |  | o Rewrite prose rule "token" in terms of "tchar", rewrite prose rule |
| "TEXT". |  | "TEXT". |
|  |  | E.4. Since draft-ietf-httpbis-p1-messaging-02 |
|  |  | Closed issues: |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/51>: "HTTP-date |
|  |  | vs. rfc1123-date" |
|  |  | o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/64>: "WS in |
|  |  | quoted-pair" |
|  |  | Ongoing work on IANA Message Header Registration |
|  |  | (<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/40>): |
|  |  | o Reference RFC 3984, and update header registrations for headers |
|  |  | defined in this document. |
|  |  | Ongoing work on ABNF conversion |
|  |  | (<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36>): |
|  |  | o Replace string literals when the string really is case-sensitive |
|  |  | (HTTP-Version). |
| Index |  | Index |
| A |  | A |
| application/http Media Type 56 |  | application/http Media Type 56 |
| C |  | C |
| cache 8 |  | cache 8 |
| cacheable 9 |  | cacheable 9 |
| client 7 |  | client 7 |
| connection 6 |  | connection 6 |
| skipping to change at page 65, line 11 |  | skipping to change at page 66, line 12 |
| field-content 25 |  | field-content 25 |
| field-name 25 |  | field-name 25 |
| field-value 25 |  | field-value 25 |
| general-header 28 |  | general-header 28 |
| generic-message 24 |  | generic-message 24 |
| HEX 15 |  | HEX 15 |
| Host 42 |  | Host 42 |
| HTAB 14 |  | HTAB 14 |
| HTTP-date 20 |  | HTTP-date 20 |
| HTTP-message 24 |  | HTTP-message 24 |
|  |  | HTTP-Prot-Name 16 |
| http-URL 18 |  | http-URL 18 |
| HTTP-Version 16 |  | HTTP-Version 16 |
| last-chunk 22 |  | last-chunk 22 |
| LF 14 |  | LF 14 |
| LWS 14 |  | LWS 14 |
| message-body 25 |  | message-body 25 |
| message-header 25 |  | message-header 25 |
| Method 29 |  | Method 29 |
| month 20 |  | month 20 |
|  |  | obsolete-date 20 |
| OCTET 14 |  | OCTET 14 |
| parameter 20 |  | parameter 20 |
| path-absolute 18 |  | path-absolute 18 |
| port 18 |  | port 18 |
| product 23 |  | product 23 |
| product-version 23 |  | product-version 23 |
| protocol-name 46 |  | protocol-name 46 |
| protocol-version 46 |  | protocol-version 46 |
| pseudonym 46 |  | pseudonym 46 |
| qdtext 15 |  | qdtext 15 |
| query 18 |  | query 18 |
| quoted-pair 15 |  | quoted-pair 15 |
| quoted-string 15 |  | quoted-string 15 |
|  |  | quoted-text 15 |
| Reason-Phrase 32 |  | Reason-Phrase 32 |
| received-by 46 |  | received-by 46 |
| received-protocol 46 |  | received-protocol 46 |
| relativeURI 18 |  | relativeURI 18 |
| Request 28 |  | Request 28 |
| Request-Line 28 |  | Request-Line 28 |
| Request-URI 29 |  | Request-URI 29 |
| Response 31 |  | Response 31 |
| rfc850-date 20 |  | rfc850-date 20 |
| rfc1123-date 20 |  | rfc1123-date 20 |
| skipping to change at page 66, line 32 |  | skipping to change at page 67, line 36 |
| Date 41 |  | Date 41 |
| Host 42 |  | Host 42 |
| TE 43 |  | TE 43 |
| Trailer 44 |  | Trailer 44 |
| Transfer-Encoding 44 |  | Transfer-Encoding 44 |
| Upgrade 45 |  | Upgrade 45 |
| Via 46 |  | Via 46 |
| Host header 42 |  | Host header 42 |
| I |  | I |
|  |  | implied *LWS 13 |
| inbound 9 |  | inbound 9 |
| M |  | M |
| Media Type |  | Media Type |
| application/http 56 |  | application/http 56 |
| message/http 54 |  | message/http 55 |
| message 6 |  | message 6 |
| message/http Media Type 54 |  | message/http Media Type 55 |
| O |  | O |
| origin server 8 |  | origin server 8 |
| outbound 9 |  | outbound 9 |
| P |  | P |
| proxy 8 |  | proxy 8 |
| R |  | R |
| representation 7 |  | representation 7 |
| request 6 |  | request 6 |
| resource 7 |  | resource 7 |
| response 6 |  | response 6 |
| S |  | S |
| server 8 |  | server 8 |
| T |  | T |
| skipping to change at page 70, line 44 |  | skipping to change at line 3284 |
| attempt made to obtain a general license or permission for the use of |  | attempt made to obtain a general license or permission for the use of |
| such proprietary rights by implementers or users of this |  | such proprietary rights by implementers or users of this |
| specification can be obtained from the IETF on-line IPR repository at |  | specification can be obtained from the IETF on-line IPR repository at |
| http://www.ietf.org/ipr. |  | http://www.ietf.org/ipr. |
| The IETF invites any interested party to bring to its attention any |  | The IETF invites any interested party to bring to its attention any |
| copyrights, patents or patent applications, or other proprietary |  | copyrights, patents or patent applications, or other proprietary |
| rights that may cover technology that may be required to implement |  | rights that may cover technology that may be required to implement |
| this standard. Please address the information to the IETF at |  | this standard. Please address the information to the IETF at |
| ietf-ipr@ietf.org. |  | ietf-ipr@ietf.org. |
| Acknowledgment |  |  |
| Funding for the RFC Editor function is provided by the IETF |  |  |
| Administrative Support Activity (IASA). |  |  |
End of changes. 34 change blocks.
| 48 lines changed or deleted |  | 100 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/