| draft-ietf-httpbis-p1-messaging-11.txt |  | draft-ietf-httpbis-p1-messaging-12.txt |
--- | --- | --- | --- | ---
| HTTPbis Working Group R. Fielding, Ed. |  | HTTPbis Working Group R. Fielding, Ed. |
| Internet-Draft Day Software |  | Internet-Draft Day Software |
| Obsoletes: 2616 (if approved) J. Gettys |  | Obsoletes: 2616 (if approved) J. Gettys |
| Updates: 2817 (if approved) Alcatel-Lucent |  | Updates: 2817 (if approved) Alcatel-Lucent |
| Intended status: Standards Track J. Mogul |  | Intended status: Standards Track J. Mogul |
| Expires: February 5, 2011 HP |  | Expires: April 28, 2011 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 4, 2010 |  | October 25, 2010 |
| 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-11 |  | draft-ietf-httpbis-p1-messaging-12 |
| Abstract |  | Abstract |
| The Hypertext Transfer Protocol (HTTP) is an application-level |  | The Hypertext Transfer Protocol (HTTP) is an application-level |
| protocol for distributed, collaborative, hypertext information |  | protocol for distributed, collaborative, hypertext 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 1, line 47 |  | skipping to change at page 1, line 47 |
| 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://tools.ietf.org/wg/httpbis/trac/report/3> and related |  | at <http://tools.ietf.org/wg/httpbis/trac/report/3> and related |
| documents (including fancy diffs) can be found at |  | documents (including fancy diffs) can be found at |
| <http://tools.ietf.org/wg/httpbis/>. |  | <http://tools.ietf.org/wg/httpbis/>. |
| The changes in this draft are summarized in Appendix D.12. |  | The changes in this draft are summarized in Appendix D.13. |
| Status of This Memo |  | Status of This Memo |
| This Internet-Draft is submitted in full conformance with the |  | This Internet-Draft is submitted in full conformance with the |
| provisions of BCP 78 and BCP 79. |  | provisions of BCP 78 and BCP 79. |
| Internet-Drafts are working documents of the Internet Engineering |  | Internet-Drafts are working documents of the Internet Engineering |
| Task Force (IETF). Note that other groups may also distribute |  | Task Force (IETF). Note that other groups may also distribute |
| working documents as Internet-Drafts. The list of current Internet- |  | working documents as Internet-Drafts. The list of current Internet- |
| Drafts is at http://datatracker.ietf.org/drafts/current/. |  | Drafts is at http://datatracker.ietf.org/drafts/current/. |
| Internet-Drafts are draft documents valid for a maximum of six months |  | Internet-Drafts are draft documents valid for a maximum of six months |
| and may be updated, replaced, or obsoleted by other documents at any |  | and may be updated, replaced, or obsoleted by other documents at any |
| time. It is inappropriate to use Internet-Drafts as reference |  | time. It is inappropriate to use Internet-Drafts as reference |
| material or to cite them other than as "work in progress." |  | material or to cite them other than as "work in progress." |
| This Internet-Draft will expire on February 5, 2011. |  | This Internet-Draft will expire on April 28, 2011. |
| Copyright Notice |  | Copyright Notice |
| Copyright (c) 2010 IETF Trust and the persons identified as the |  | Copyright (c) 2010 IETF Trust and the persons identified as the |
| document authors. All rights reserved. |  | document authors. All rights reserved. |
| This document is subject to BCP 78 and the IETF Trust's Legal |  | This document is subject to BCP 78 and the IETF Trust's Legal |
| Provisions Relating to IETF Documents |  | Provisions Relating to IETF Documents |
| (http://trustee.ietf.org/license-info) in effect on the date of |  | (http://trustee.ietf.org/license-info) in effect on the date of |
| publication of this document. Please review these documents |  | publication of this document. Please review these documents |
| skipping to change at page 3, line 40 |  | skipping to change at page 3, line 40 |
| 5.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 31 |  | 5.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 31 |
| 6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 32 |  | 6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 32 |
| 6.1. Date/Time Formats: Full Date . . . . . . . . . . . . . . . 32 |  | 6.1. Date/Time Formats: Full Date . . . . . . . . . . . . . . . 32 |
| 6.2. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 34 |  | 6.2. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 34 |
| 6.2.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 35 |  | 6.2.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 35 |
| 6.2.2. Compression Codings . . . . . . . . . . . . . . . . . 37 |  | 6.2.2. Compression Codings . . . . . . . . . . . . . . . . . 37 |
| 6.2.3. Transfer Coding Registry . . . . . . . . . . . . . . . 38 |  | 6.2.3. Transfer Coding Registry . . . . . . . . . . . . . . . 38 |
| 6.3. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 39 |  | 6.3. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 39 |
| 6.4. Quality Values . . . . . . . . . . . . . . . . . . . . . . 39 |  | 6.4. Quality Values . . . . . . . . . . . . . . . . . . . . . . 39 |
| 7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 39 |  | 7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 39 |
| 7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 39 |  | 7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 40 |
| 7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 40 |  | 7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 40 |
| 7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 40 |  | 7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 40 |
| 7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 42 |  | 7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 42 |
| 7.1.4. Practical Considerations . . . . . . . . . . . . . . . 44 |  | 7.1.4. Practical Considerations . . . . . . . . . . . . . . . 44 |
| 7.2. Message Transmission Requirements . . . . . . . . . . . . 45 |  | 7.2. Message Transmission Requirements . . . . . . . . . . . . 45 |
| 7.2.1. Persistent Connections and Flow Control . . . . . . . 45 |  | 7.2.1. Persistent Connections and Flow Control . . . . . . . 45 |
| 7.2.2. Monitoring Connections for Error Status Messages . . . 45 |  | 7.2.2. Monitoring Connections for Error Status Messages . . . 45 |
| 7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 46 |  | 7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 46 |
| 7.2.4. Client Behavior if Server Prematurely Closes |  | 7.2.4. Client Behavior if Server Prematurely Closes |
| Connection . . . . . . . . . . . . . . . . . . . . . . 48 |  | Connection . . . . . . . . . . . . . . . . . . . . . . 48 |
| skipping to change at page 4, line 50 |  | skipping to change at page 4, line 50 |
| Appendix A. Tolerant Applications . . . . . . . . . . . . . . . . 70 |  | Appendix A. Tolerant Applications . . . . . . . . . . . . . . . . 70 |
| Appendix B. Compatibility with Previous Versions . . . . . . . . 71 |  | Appendix B. Compatibility with Previous Versions . . . . . . . . 71 |
| B.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 71 |  | B.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 71 |
| B.1.1. Changes to Simplify Multi-homed Web Servers and |  | B.1.1. Changes to Simplify Multi-homed Web Servers and |
| Conserve IP Addresses . . . . . . . . . . . . . . . . 72 |  | Conserve IP Addresses . . . . . . . . . . . . . . . . 72 |
| B.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 72 |  | B.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 72 |
| B.3. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 73 |  | B.3. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 73 |
| Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 74 |  | Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 74 |
| Appendix D. Change Log (to be removed by RFC Editor before |  | Appendix D. Change Log (to be removed by RFC Editor before |
| publication) . . . . . . . . . . . . . . . . . . . . 78 |  | publication) . . . . . . . . . . . . . . . . . . . . 78 |
| D.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 78 |  | D.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 78 |
| D.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 78 |  | D.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 78 |
| D.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 80 |  | D.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 80 |
| D.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 81 |  | D.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 81 |
| D.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 81 |  | D.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 81 |
| D.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 82 |  | D.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 82 |
| D.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 82 |  | D.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 82 |
| D.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 83 |  | D.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 83 |
| D.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 84 |  | D.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 84 |
| D.10. Since draft-ietf-httpbis-p1-messaging-08 . . . . . . . . . 84 |  | D.10. Since draft-ietf-httpbis-p1-messaging-08 . . . . . . . . . 84 |
| D.11. Since draft-ietf-httpbis-p1-messaging-09 . . . . . . . . . 85 |  | D.11. Since draft-ietf-httpbis-p1-messaging-09 . . . . . . . . . 85 |
| D.12. Since draft-ietf-httpbis-p1-messaging-10 . . . . . . . . . 85 |  | D.12. Since draft-ietf-httpbis-p1-messaging-10 . . . . . . . . . 85 |
|  |  | D.13. Since draft-ietf-httpbis-p1-messaging-11 . . . . . . . . . 86 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 |
| 1. Introduction |  | 1. Introduction |
| The Hypertext Transfer Protocol (HTTP) is an application-level |  | The Hypertext Transfer Protocol (HTTP) is an application-level |
| request/response protocol that uses extensible semantics and MIME- |  | request/response protocol that uses extensible semantics and MIME- |
| like message payloads for flexible interaction with network-based |  | like message payloads for flexible interaction with network-based |
| hypertext information systems. HTTP relies upon the Uniform Resource |  | hypertext information systems. HTTP relies upon the Uniform Resource |
| Identifier (URI) standard [RFC3986] to indicate request targets and |  | Identifier (URI) standard [RFC3986] to indicate request targets and |
| relationships between resources. Messages are passed in a format |  | relationships between resources. Messages are passed in a format |
| skipping to change at page 21, line 39 |  | skipping to change at page 21, line 39 |
| message unless the entire field value for that header field is |  | message unless the entire field value for that header field is |
| defined as a comma-separated list [i.e., #(values)]. Multiple header |  | defined as a comma-separated list [i.e., #(values)]. Multiple header |
| fields with the same field name can be combined into one "field-name: |  | fields with the same field name can be combined into one "field-name: |
| field-value" pair, without changing the semantics of the message, by |  | field-value" pair, without changing the semantics of the message, by |
| appending each subsequent field value to the combined field value in |  | appending each subsequent field value to the combined field value in |
| order, separated by a comma. The order in which header fields with |  | order, separated by a comma. The order in which header fields with |
| the same field name are received is therefore significant to the |  | the same field name are received is therefore significant to the |
| interpretation of the combined field value; a proxy MUST NOT change |  | interpretation of the combined field value; a proxy MUST NOT change |
| the order of these field values when forwarding a message. |  | the order of these field values when forwarding a message. |
| Note: The "Set-Cookie" header as implemented in practice (as |  | Note: The "Set-Cookie" header field as implemented in practice (as |
| opposed to how it is specified in [RFC2109]) can occur multiple |  | opposed to how it is specified in [RFC2109]) can occur multiple |
| times, but does not use the list syntax, and thus cannot be |  | times, but does not use the list syntax, and thus cannot be |
| combined into a single line. (See Appendix A.2.3 of [Kri2001] for |  | combined into a single line. (See Appendix A.2.3 of [Kri2001] for |
| details.) Also note that the Set-Cookie2 header specified in |  | details.) Also note that the Set-Cookie2 header field specified |
| [RFC2965] does not share this problem. |  | in [RFC2965] does not share this problem. |
| Historically, HTTP header field values could be extended over |  | Historically, HTTP header field values could be extended over |
| multiple lines by preceding each extra line with at least one space |  | multiple lines by preceding each extra line with at least one space |
| or horizontal tab character (line folding). This specification |  | or horizontal tab character (line folding). This specification |
| deprecates such line folding except within the message/http media |  | deprecates such line folding except within the message/http media |
| type (Section 10.3.1). HTTP/1.1 senders MUST NOT produce messages |  | type (Section 10.3.1). HTTP/1.1 senders MUST NOT produce messages |
| that include line folding (i.e., that contain any field-content that |  | that include line folding (i.e., that contain any field-content that |
| matches the obs-fold rule) unless the message is intended for |  | matches the obs-fold rule) unless the message is intended for |
| packaging within the message/http media type. HTTP/1.1 recipients |  | packaging within the message/http media type. HTTP/1.1 recipients |
| SHOULD accept line folding and replace any embedded obs-fold |  | SHOULD accept line folding and replace any embedded obs-fold |
| skipping to change at page 24, line 16 |  | skipping to change at page 24, line 16 |
| 3. If a message is received without Transfer-Encoding and with |  | 3. If a message is received without Transfer-Encoding and with |
| either multiple Content-Length header fields or a single Content- |  | either multiple Content-Length header fields or a single Content- |
| Length header field with an invalid value, then the message |  | Length header field with an invalid value, then the message |
| framing is invalid and MUST be treated as an error to prevent |  | framing is invalid and MUST be treated as an error to prevent |
| request or response smuggling. If this is a request message, the |  | request or response smuggling. If this is a request message, the |
| server MUST respond with a 400 (Bad Request) status code and then |  | server MUST respond with a 400 (Bad Request) status code and then |
| close the connection. If this is a response message received by |  | close the connection. If this is a response message received by |
| a proxy or gateway, the proxy or gateway MUST discard the |  | a proxy or gateway, the proxy or gateway MUST discard the |
| received response, send a 502 (Bad Gateway) status code as its |  | received response, send a 502 (Bad Gateway) status code as its |
| downstream response, and then close the connection. If this is a |  | downstream response, and then close the connection. If this is a |
| response message received by a user-agent, the message-body |  | response message received by a user-agent, it SHOULD be treated |
| length is determined by reading the connection until it is |  | as an error by discarding the message and closing the connection. |
| closed; an error SHOULD be indicated to the user. |  |  |
| 4. If a valid Content-Length header field (Section 9.2) is present |  | 4. If a valid Content-Length header field (Section 9.2) is present |
| without Transfer-Encoding, its decimal value defines the message- |  | without Transfer-Encoding, its decimal value defines the message- |
| body length in octets. If the actual number of octets sent in |  | body length in octets. If the actual number of octets sent in |
| the message is less than the indicated Content-Length, the |  | the message is less than the indicated Content-Length, the |
| recipient MUST consider the message to be incomplete and treat |  | recipient MUST consider the message to be incomplete and treat |
| the connection as no longer usable. If the actual number of |  | the connection as no longer usable. If the actual number of |
| octets sent in the message is more than the indicated Content- |  | octets sent in the message is more than the indicated Content- |
| Length, the recipient MUST only process the message-body up to |  | Length, the recipient MUST only process the message-body up to |
| the field value's number of octets; the remainder of the message |  | the field value's number of octets; the remainder of the message |
| skipping to change at page 27, line 18 |  | skipping to change at page 27, line 18 |
| request. |  | request. |
| request-target = "*" |  | request-target = "*" |
| / absolute-URI |  | / absolute-URI |
| / ( path-absolute [ "?" query ] ) |  | / ( path-absolute [ "?" query ] ) |
| / authority |  | / authority |
| The four options for request-target are dependent on the nature of |  | The four options for request-target are dependent on the nature of |
| the request. |  | the request. |
| The asterisk "*" means that the request does not apply to a |  | The asterisk "*" ("asterisk form") means that the request does not |
| particular resource, but to the server itself, and is only allowed |  | apply to a particular resource, but to the server itself, and is only |
| when the method used does not necessarily apply to a resource. One |  | allowed when the method used does not necessarily apply to a |
| example would be |  | resource. One example would be |
| OPTIONS * HTTP/1.1 |  | OPTIONS * HTTP/1.1 |
| The absolute-URI form is REQUIRED when the request is being made to a |  | The absolute-URI form is REQUIRED when the request is being made to a |
| proxy. The proxy is requested to forward the request or service it |  | proxy. The proxy is requested to forward the request or service it |
| from a valid cache, and return the response. Note that the proxy MAY |  | from a valid cache, and return the response. Note that the proxy MAY |
| forward the request on to another proxy or directly to the server |  | forward the request on to another proxy or directly to the server |
| specified by the absolute-URI. In order to avoid request loops, a |  | specified by the absolute-URI. In order to avoid request loops, a |
| proxy MUST be able to recognize all of its server names, including |  | proxy MUST be able to recognize all of its server names, including |
| any aliases, local variations, and the numeric IP address. An |  | any aliases, local variations, and the numeric IP address. An |
| skipping to change at page 27, line 45 |  | skipping to change at page 27, line 45 |
| To allow for transition to absolute-URIs in all requests in future |  | To allow for transition to absolute-URIs in all requests in future |
| versions of HTTP, all HTTP/1.1 servers MUST accept the absolute-URI |  | versions of HTTP, all HTTP/1.1 servers MUST accept the absolute-URI |
| form in requests, even though HTTP/1.1 clients will only generate |  | form in requests, even though HTTP/1.1 clients will only generate |
| them in requests to proxies. |  | them in requests to proxies. |
| The authority form is only used by the CONNECT method (Section 7.9 of |  | The authority form is only used by the CONNECT method (Section 7.9 of |
| [Part2]). |  | [Part2]). |
| The most common form of request-target is that used to identify a |  | The most common form of request-target is that used to identify a |
| resource on an origin server or gateway. In this case the absolute |  | resource on an origin server or gateway ("path-absolute form"). In |
| path of the URI MUST be transmitted (see Section 2.6.1, path- |  | this case the absolute path of the URI MUST be transmitted (see |
| absolute) as the request-target, and the network location of the URI |  | Section 2.6.1, path-absolute) as the request-target, and the network |
| (authority) MUST be transmitted in a Host header field. For example, |  | location of the URI (authority) MUST be transmitted in a Host header |
| a client wishing to retrieve the resource above directly from the |  | field. For example, a client wishing to retrieve the resource above |
| origin server would create a TCP connection to port 80 of the host |  | directly from the origin server would create a TCP connection to port |
| "www.example.org" and send the lines: |  | 80 of the host "www.example.org" and send the lines: |
| GET /pub/WWW/TheProject.html HTTP/1.1 |  | GET /pub/WWW/TheProject.html HTTP/1.1 |
| Host: www.example.org |  | Host: www.example.org |
| followed by the remainder of the Request. Note that the absolute |  | followed by the remainder of the Request. Note that the absolute |
| path cannot be empty; if none is present in the original URI, it MUST |  | path cannot be empty; if none is present in the original URI, it MUST |
| be given as "/" (the server root). |  | be given as "/" (the server root). |
| If a proxy receives a request without any path in the request-target |  | If a proxy receives a request without any path in the request-target |
| and the method specified is capable of supporting the asterisk form |  | and the method specified is capable of supporting the asterisk form |
| skipping to change at page 30, line 6 |  | skipping to change at page 30, line 6 |
| HTTP requests often do not carry the absolute URI ([RFC3986], Section |  | HTTP requests often do not carry the absolute URI ([RFC3986], Section |
| 4.3) for the target resource; instead, the URI needs to be inferred |  | 4.3) for the target resource; instead, the URI needs to be inferred |
| from the request-target, Host header field, and connection context. |  | from the request-target, Host header field, and connection context. |
| The result of this process is called the "effective request URI". |  | The result of this process is called the "effective request URI". |
| The "target resource" is the resource identified by the effective |  | The "target resource" is the resource identified by the effective |
| request URI. |  | request URI. |
| If the request-target is an absolute-URI, then the effective request |  | If the request-target is an absolute-URI, then the effective request |
| URI is the request-target. |  | URI is the request-target. |
| If the request-target uses the path-absolute (plus optional query) |  | If the request-target uses the path-absolute form or the asterisk |
| syntax or if it is just the asterisk "*", then the effective request |  | form, and the Host header field is present, then the effective |
| URI is constructed by concatenating |  | request URI is constructed by concatenating |
| o the scheme name: "http" if the request was received over an |  | o the scheme name: "http" if the request was received over an |
| insecure TCP connection, or "https" when received over a SSL/ |  | insecure TCP connection, or "https" when received over a SSL/ |
| TLS-secured TCP connection, |  | TLS-secured TCP connection, |
| o the character sequence "://", |  | o the character sequence "://", |
| o the authority component, as specified in the Host header |  | o the authority component, as specified in the Host header field |
| (Section 9.4) and determined by the rules in Section 4.2, |  | (Section 9.4), and |
| [[effrequri-nohost: Do we need to include the handling of missing |  |  |
| hosts in HTTP/1.0 messages, as described in Section 4.2? -- See |  |  |
| <http://tools.ietf.org/wg/httpbis/trac/ticket/221> --jre]] and |  |  |
| o the request-target obtained from the Request-Line, unless the |  | o the request-target obtained from the Request-Line, unless the |
| request-target is just the asterisk "*". |  | request-target is just the asterisk "*". |
|  |  | If the request-target uses the path-absolute form or the asterisk |
|  |  | form, and the Host header field is not present, then the effective |
|  |  | request URI is undefined. |
| Otherwise, when request-target uses the authority form, the effective |  | Otherwise, when request-target uses the authority form, the effective |
| Request URI is undefined. |  | request URI is undefined. |
| Example 1: the effective request URI for the message |  | Example 1: the effective request URI for the message |
| GET /pub/WWW/TheProject.html HTTP/1.1 |  | GET /pub/WWW/TheProject.html HTTP/1.1 |
| Host: www.example.org:8080 |  | Host: www.example.org:8080 |
| (received over an insecure TCP connection) is "http", plus "://", |  | (received over an insecure TCP connection) is "http", plus "://", |
| plus the authority component "www.example.org:8080", plus the |  | plus the authority component "www.example.org:8080", plus the |
| request-target "/pub/WWW/TheProject.html", thus |  | request-target "/pub/WWW/TheProject.html", thus |
| "http://www.example.org:8080/pub/WWW/TheProject.html". |  | "http://www.example.org:8080/pub/WWW/TheProject.html". |
| skipping to change at page 33, line 6 |  | skipping to change at page 33, line 6 |
| 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 whitespace beyond that specifically included as SP in the |  | additional whitespace beyond that specifically included as SP in the |
| grammar. |  | grammar. |
| HTTP-date = rfc1123-date / obs-date |  | HTTP-date = rfc1123-date / obs-date |
| Preferred format: |  | Preferred format: |
| rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT |  | rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT |
|  |  | ; fixed length subset of the format defined in |
|  |  | ; Section 5.2.14 of [RFC1123] |
| day-name = %x4D.6F.6E ; "Mon", case-sensitive |  | day-name = %x4D.6F.6E ; "Mon", case-sensitive |
| / %x54.75.65 ; "Tue", case-sensitive |  | / %x54.75.65 ; "Tue", case-sensitive |
| / %x57.65.64 ; "Wed", case-sensitive |  | / %x57.65.64 ; "Wed", case-sensitive |
| / %x54.68.75 ; "Thu", case-sensitive |  | / %x54.68.75 ; "Thu", case-sensitive |
| / %x46.72.69 ; "Fri", case-sensitive |  | / %x46.72.69 ; "Fri", case-sensitive |
| / %x53.61.74 ; "Sat", case-sensitive |  | / %x53.61.74 ; "Sat", case-sensitive |
| / %x53.75.6E ; "Sun", case-sensitive |  | / %x53.75.6E ; "Sun", case-sensitive |
| date1 = day SP month SP year |  | date1 = day SP month SP year |
| skipping to change at page 36, line 23 |  | skipping to change at page 36, line 23 |
| Section 9.6). |  | Section 9.6). |
| A server using chunked transfer-coding in a response MUST NOT use the |  | A server using chunked transfer-coding in a response MUST NOT use the |
| trailer for any header fields unless at least one of the following is |  | trailer for any header fields unless at least one of the following is |
| true: |  | true: |
| 1. the request included a TE header field that indicates "trailers" |  | 1. the request included a TE header field that indicates "trailers" |
| is acceptable in the transfer-coding of the response, as |  | is acceptable in the transfer-coding of the response, as |
| described in Section 9.5; or, |  | described in Section 9.5; or, |
| 2. the server is the origin server for the response, the trailer |  | 2. the trailer fields consist entirely of optional metadata, and the |
| fields consist entirely of optional metadata, and the recipient |  | recipient could use the message (in a manner acceptable to the |
| could use the message (in a manner acceptable to the origin |  | server where the field originated) without receiving it. In |
| server) without receiving this metadata. In other words, the |  | other words, the server that generated the header (often but not |
| origin server is willing to accept the possibility that the |  | always the origin server) is willing to accept the possibility |
| trailer fields might be silently discarded along the path to the |  | that the trailer fields might be silently discarded along the |
| client. |  | path to the client. |
| This requirement prevents an interoperability failure when the |  | This requirement prevents an interoperability failure when the |
| message is being received by an HTTP/1.1 (or later) proxy and |  | message is being received by an HTTP/1.1 (or later) proxy and |
| forwarded to an HTTP/1.0 recipient. It avoids a situation where |  | forwarded to an HTTP/1.0 recipient. It avoids a situation where |
| compliance with the protocol would have necessitated a possibly |  | compliance with the protocol would have necessitated a possibly |
| infinite buffer on the proxy. |  | infinite buffer on the proxy. |
| A process for decoding the "chunked" transfer-coding can be |  | A process for decoding the "chunked" transfer-coding can be |
| represented in pseudo-code as: |  | represented in pseudo-code as: |
| skipping to change at page 39, line 31 |  | skipping to change at page 39, line 31 |
| Product tokens SHOULD be short and to the point. They MUST NOT be |  | Product tokens SHOULD be short and to the point. They MUST NOT be |
| used for advertising or other non-essential information. Although |  | used for advertising or other non-essential information. Although |
| any token character MAY appear in a product-version, this token |  | any token character MAY appear in a product-version, this token |
| SHOULD only be used for a version identifier (i.e., successive |  | SHOULD only be used for a version identifier (i.e., successive |
| versions of the same product SHOULD only differ in the product- |  | versions of the same product SHOULD only differ in the product- |
| version portion of the product value). |  | version portion of the product value). |
| 6.4. Quality Values |  | 6.4. Quality Values |
| Both transfer codings (TE request header, Section 9.5) and content |  | Both transfer codings (TE request header field, Section 9.5) and |
| negotiation (Section 5 of [Part3]) use short "floating point" numbers |  | content negotiation (Section 5 of [Part3]) use short "floating point" |
| to indicate the relative importance ("weight") of various negotiable |  | numbers to indicate the relative importance ("weight") of various |
| parameters. A weight is normalized to a real number in the range 0 |  | negotiable parameters. A weight is normalized to a real number in |
| through 1, where 0 is the minimum and 1 the maximum value. If a |  | the range 0 through 1, where 0 is the minimum and 1 the maximum |
| parameter has a quality value of 0, then content with this parameter |  | value. If a parameter has a quality value of 0, then content with |
| is "not acceptable" for the client. HTTP/1.1 applications MUST NOT |  | this parameter is "not acceptable" for the client. HTTP/1.1 |
| generate more than three digits after the decimal point. User |  | applications MUST NOT generate more than three digits after the |
| configuration of these values SHOULD also be limited in this fashion. |  | decimal point. User configuration of these values SHOULD also be |
|  |  | limited in this fashion. |
| qvalue = ( "0" [ "." 0*3DIGIT ] ) |  | qvalue = ( "0" [ "." 0*3DIGIT ] ) |
| / ( "1" [ "." 0*3("0") ] ) |  | / ( "1" [ "." 0*3("0") ] ) |
| Note: "Quality values" is a misnomer, since these values merely |  | Note: "Quality values" is a misnomer, since these values merely |
| represent relative degradation in desired quality. |  | represent relative degradation in desired quality. |
| 7. Connections |  | 7. Connections |
| 7.1. Persistent Connections |  | 7.1. Persistent Connections |
| 7.1.1. Purpose |  | 7.1.1. Purpose |
| Prior to persistent connections, a separate TCP connection was |  | Prior to persistent connections, a separate TCP connection was |
| established to fetch each URL, increasing the load on HTTP servers |  | established to fetch each URL, increasing the load on HTTP servers |
| and causing congestion on the Internet. The use of inline images and |  | and causing congestion on the Internet. The use of inline images and |
| other associated data often requires a client to make multiple |  | other associated data often requires a client to make multiple |
| requests of the same server in a short amount of time. Analysis of |  | requests of the same server in a short amount of time. Analysis of |
| these performance problems and results from a prototype |  | these performance problems and results from a prototype |
| implementation are available [Pad1995] [Spe]. Implementation |  | implementation are available [Pad1995] [Spe]. Implementation |
| experience and measurements of actual HTTP/1.1 implementations show |  | experience and measurements of actual HTTP/1.1 implementations show |
| skipping to change at page 41, line 14 |  | skipping to change at page 41, line 15 |
| Persistent connections provide a mechanism by which a client and a |  | Persistent connections provide a mechanism by which a client and a |
| server can signal the close of a TCP connection. This signaling |  | server can signal the close of a TCP connection. This signaling |
| takes place using the Connection header field (Section 9.1). Once a |  | takes place using the Connection header field (Section 9.1). Once a |
| close has been signaled, the client MUST NOT send any more requests |  | close has been signaled, the client MUST NOT send any more requests |
| on that connection. |  | on that connection. |
| 7.1.2.1. Negotiation |  | 7.1.2.1. Negotiation |
| An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to |  | An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to |
| maintain a persistent connection unless a Connection header including |  | maintain a persistent connection unless a Connection header field |
| the connection-token "close" was sent in the request. If the server |  | including the connection-token "close" was sent in the request. If |
| chooses to close the connection immediately after sending the |  | the server chooses to close the connection immediately after sending |
| response, it SHOULD send a Connection header including the |  | the response, it SHOULD send a Connection header field including the |
| connection-token "close". |  | connection-token "close". |
| An HTTP/1.1 client MAY expect a connection to remain open, but would |  | An HTTP/1.1 client MAY expect a connection to remain open, but would |
| decide to keep it open based on whether the response from a server |  | decide to keep it open based on whether the response from a server |
| contains a Connection header with the connection-token close. In |  | contains a Connection header field with the connection-token close. |
| case the client does not want to maintain a connection for more than |  | In case the client does not want to maintain a connection for more |
| that request, it SHOULD send a Connection header including the |  | than that request, it SHOULD send a Connection header field including |
| connection-token close. |  | the connection-token close. |
| If either the client or the server sends the close token in the |  | If either the client or the server sends the close token in the |
| Connection header, that request becomes the last one for the |  | Connection header field, that request becomes the last one for the |
| connection. |  | connection. |
| Clients and servers SHOULD NOT assume that a persistent connection is |  | Clients and servers SHOULD NOT assume that a persistent connection is |
| maintained for HTTP versions less than 1.1 unless it is explicitly |  | maintained for HTTP versions less than 1.1 unless it is explicitly |
| signaled. See Appendix B.2 for more information on backward |  | signaled. See Appendix B.2 for more information on backward |
| compatibility with HTTP/1.0 clients. |  | compatibility with HTTP/1.0 clients. |
| In order to remain persistent, all messages on the connection MUST |  | In order to remain persistent, all messages on the connection MUST |
| have a self-defined message length (i.e., one not defined by closure |  | have a self-defined message length (i.e., one not defined by closure |
| of the connection), as described in Section 3.3. |  | of the connection), as described in Section 3.3. |
| skipping to change at page 42, line 27 |  | skipping to change at page 42, line 29 |
| Section 9.1. |  | Section 9.1. |
| The proxy server MUST signal persistent connections separately with |  | The proxy server MUST signal persistent connections separately with |
| its clients and the origin servers (or other proxy servers) that it |  | its clients and the origin servers (or other proxy servers) that it |
| connects to. Each persistent connection applies to only one |  | connects to. Each persistent connection applies to only one |
| transport link. |  | transport link. |
| A proxy server MUST NOT establish a HTTP/1.1 persistent connection |  | A proxy server MUST NOT establish a HTTP/1.1 persistent connection |
| with an HTTP/1.0 client (but see Section 19.7.1 of [RFC2068] for |  | with an HTTP/1.0 client (but see Section 19.7.1 of [RFC2068] for |
| information and discussion of the problems with the Keep-Alive header |  | information and discussion of the problems with the Keep-Alive header |
| implemented by many HTTP/1.0 clients). |  | field implemented by many HTTP/1.0 clients). |
| 7.1.3.1. End-to-end and Hop-by-hop Headers |  | 7.1.3.1. End-to-end and Hop-by-hop Header Fields |
| For the purpose of defining the behavior of caches and non-caching |  | For the purpose of defining the behavior of caches and non-caching |
| proxies, we divide HTTP headers into two categories: |  | proxies, we divide HTTP header fields into two categories: |
| o End-to-end headers, which are transmitted to the ultimate |  | o End-to-end header fields, which are transmitted to the ultimate |
| recipient of a request or response. End-to-end headers in |  | recipient of a request or response. End-to-end header fields in |
| responses MUST be stored as part of a cache entry and MUST be |  | responses MUST be stored as part of a cache entry and MUST be |
| transmitted in any response formed from a cache entry. |  | transmitted in any response formed from a cache entry. |
| o Hop-by-hop headers, which are meaningful only for a single |  | o Hop-by-hop header fields, which are meaningful only for a single |
| transport-level connection, and are not stored by caches or |  | transport-level connection, and are not stored by caches or |
| forwarded by proxies. |  | forwarded by proxies. |
| The following HTTP/1.1 headers are hop-by-hop headers: |  | The following HTTP/1.1 header fields are hop-by-hop header fields: |
| o Connection |  | o Connection |
| o Keep-Alive |  | o Keep-Alive |
| o Proxy-Authenticate |  | o Proxy-Authenticate |
| o Proxy-Authorization |  | o Proxy-Authorization |
| o TE |  | o TE |
| o Trailer |  | o Trailer |
| o Transfer-Encoding |  | o Transfer-Encoding |
| o Upgrade |  | o Upgrade |
| skipping to change at page 43, line 14 |  | skipping to change at page 43, line 16 |
| o Proxy-Authorization |  | o Proxy-Authorization |
| o TE |  | o TE |
| o Trailer |  | o Trailer |
| o Transfer-Encoding |  | o Transfer-Encoding |
| o Upgrade |  | o Upgrade |
| All other headers defined by HTTP/1.1 are end-to-end headers. |  | All other header fields defined by HTTP/1.1 are end-to-end header |
|  |  | fields. |
| Other hop-by-hop headers MUST be listed in a Connection header |  | Other hop-by-hop header fields MUST be listed in a Connection header |
| (Section 9.1). |  | field (Section 9.1). |
| 7.1.3.2. Non-modifiable Headers |  | 7.1.3.2. Non-modifiable Header Fields |
| Some features of HTTP/1.1, such as Digest Authentication, depend on |  | Some features of HTTP/1.1, such as Digest Authentication, depend on |
| the value of certain end-to-end headers. A transparent proxy SHOULD |  | the value of certain end-to-end header fields. A transparent proxy |
| NOT modify an end-to-end header unless the definition of that header |  | SHOULD NOT modify an end-to-end header field unless the definition of |
| requires or specifically allows that. |  | that header field requires or specifically allows that. |
| A transparent proxy MUST NOT modify any of the following fields in a |  | A transparent proxy MUST NOT modify any of the following fields in a |
| request or response, and it MUST NOT add any of these fields if not |  | request or response, and it MUST NOT add any of these fields if not |
| already present: |  | already present: |
| o Content-Location |  | o Content-Location |
| o Content-MD5 |  | o Content-MD5 |
| o ETag |  | o ETag |
| o Last-Modified |  | o Last-Modified |
| A transparent proxy MUST NOT modify any of the following fields in a |  | A transparent proxy MUST NOT modify any of the following fields in a |
| response: |  | response: |
| o Expires |  | o Expires |
| but it MAY add any of these fields if not already present. If an |  | but it MAY add any of these fields if not already present. If an |
| Expires header is added, it MUST be given a field-value identical to |  | Expires header field is added, it MUST be given a field-value |
| that of the Date header in that response. |  | identical to that of the Date header field in that response. |
| A proxy MUST NOT modify or add any of the following fields in a |  | A proxy MUST NOT modify or add any of the following fields in a |
| message that contains the no-transform cache-control directive, or in |  | message that contains the no-transform cache-control directive, or in |
| any request: |  | any request: |
| o Content-Encoding |  | o Content-Encoding |
| o Content-Range |  | o Content-Range |
| o Content-Type |  | o Content-Type |
| A non-transparent proxy MAY modify or add these fields to a message |  | A non-transparent proxy MAY modify or add these fields to a message |
| that does not include no-transform, but if it does so, it MUST add a |  | that does not include no-transform, but if it does so, it MUST add a |
| Warning 214 (Transformation applied) if one does not already appear |  | Warning 214 (Transformation applied) if one does not already appear |
| in the message (see Section 3.6 of [Part6]). |  | in the message (see Section 3.6 of [Part6]). |
| Warning: Unnecessary modification of end-to-end headers might |  | Warning: Unnecessary modification of end-to-end header fields |
| cause authentication failures if stronger authentication |  | might cause authentication failures if stronger authentication |
| mechanisms are introduced in later versions of HTTP. Such |  | mechanisms are introduced in later versions of HTTP. Such |
| authentication mechanisms MAY rely on the values of header fields |  | authentication mechanisms MAY rely on the values of header fields |
| not listed here. |  | not listed here. |
| A transparent proxy MUST preserve the message payload ([Part3]), |  | A transparent proxy MUST preserve the message payload ([Part3]), |
| though it MAY change the message-body through application or removal |  | though it MAY change the message-body through application or removal |
| of a transfer-coding (Section 6.2). |  | of a transfer-coding (Section 6.2). |
| 7.1.4. Practical Considerations |  | 7.1.4. Practical Considerations |
| skipping to change at page 46, line 6 |  | skipping to change at page 46, line 8 |
| The latter technique can exacerbate network congestion. |  | The latter technique can exacerbate network congestion. |
| 7.2.2. Monitoring Connections for Error Status Messages |  | 7.2.2. Monitoring Connections for Error Status Messages |
| An HTTP/1.1 (or later) client sending a message-body SHOULD monitor |  | An HTTP/1.1 (or later) client sending a message-body SHOULD monitor |
| the network connection for an error status code while it is |  | the network connection for an error status code while it is |
| transmitting the request. If the client sees an error status code, |  | transmitting the request. If the client sees an error status code, |
| it SHOULD immediately cease transmitting the body. If the body is |  | it SHOULD immediately cease transmitting the body. If the body is |
| being sent using a "chunked" encoding (Section 6.2), a zero length |  | being sent using a "chunked" encoding (Section 6.2), a zero length |
| chunk and empty trailer MAY be used to prematurely mark the end of |  | chunk and empty trailer MAY be used to prematurely mark the end of |
| the message. If the body was preceded by a Content-Length header, |  | the message. If the body was preceded by a Content-Length header |
| the client MUST close the connection. |  | field, the client MUST close the connection. |
| 7.2.3. Use of the 100 (Continue) Status |  | 7.2.3. Use of the 100 (Continue) Status |
| The purpose of the 100 (Continue) status code (see Section 8.1.1 of |  | The purpose of the 100 (Continue) status code (see Section 8.1.1 of |
| [Part2]) is to allow a client that is sending a request message with |  | [Part2]) is to allow a client that is sending a request message with |
| a request body to determine if the origin server is willing to accept |  | a request body to determine if the origin server is willing to accept |
| the request (based on the request headers) before the client sends |  | the request (based on the request header fields) before the client |
| the request body. In some cases, it might either be inappropriate or |  | sends the request body. In some cases, it might either be |
| highly inefficient for the client to send the body if the server will |  | inappropriate or highly inefficient for the client to send the body |
| reject the message without looking at the body. |  | if the server will reject the message without looking at the body. |
| Requirements for HTTP/1.1 clients: |  | Requirements for HTTP/1.1 clients: |
| o If a client will wait for a 100 (Continue) response before sending |  | o If a client will wait for a 100 (Continue) response before sending |
| the request body, it MUST send an Expect request-header field |  | the request body, it MUST send an Expect request-header field |
| (Section 9.2 of [Part2]) with the "100-continue" expectation. |  | (Section 9.2 of [Part2]) with the "100-continue" expectation. |
| o A client MUST NOT send an Expect request-header field (Section 9.2 |  | o A client MUST NOT send an Expect request-header field (Section 9.2 |
| of [Part2]) with the "100-continue" expectation if it does not |  | of [Part2]) with the "100-continue" expectation if it does not |
| intend to send a request body. |  | intend to send a request body. |
| skipping to change at page 48, line 24 |  | skipping to change at page 48, line 27 |
| but which does not include an Expect request-header field with the |  | but which does not include an Expect request-header field with the |
| "100-continue" expectation, and if the client is not directly |  | "100-continue" expectation, and if the client is not directly |
| connected to an HTTP/1.1 origin server, and if the client sees the |  | connected to an HTTP/1.1 origin server, and if the client sees the |
| connection close before receiving a status line from the server, the |  | connection close before receiving a status line from the server, the |
| client SHOULD retry the request. If the client does retry this |  | client SHOULD retry the request. If the client does retry this |
| request, it MAY use the following "binary exponential backoff" |  | request, it MAY use the following "binary exponential backoff" |
| algorithm to be assured of obtaining a reliable response: |  | algorithm to be assured of obtaining a reliable response: |
| 1. Initiate a new connection to the server |  | 1. Initiate a new connection to the server |
| 2. Transmit the request-headers |  | 2. Transmit the request-header fields |
| 3. Initialize a variable R to the estimated round-trip time to the |  | 3. Initialize a variable R to the estimated round-trip time to the |
| server (e.g., based on the time it took to establish the |  | server (e.g., based on the time it took to establish the |
| connection), or to a constant value of 5 seconds if the round- |  | connection), or to a constant value of 5 seconds if the round- |
| trip time is not available. |  | trip time is not available. |
| 4. Compute T = R * (2**N), where N is the number of previous retries |  | 4. Compute T = R * (2**N), where N is the number of previous retries |
| of this request. |  | of this request. |
| 5. Wait either for an error response from the server, or for T |  | 5. Wait either for an error response from the server, or for T |
| skipping to change at page 49, line 43 |  | skipping to change at page 49, line 45 |
| 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 message framing and transport protocols. |  | fields related to message framing and transport protocols. |
| 9.1. Connection |  | 9.1. Connection |
| The "Connection" general-header field allows the sender to specify |  | The "Connection" general-header field allows the sender to specify |
| options that are desired for that particular connection and MUST NOT |  | options that are desired for that particular connection and MUST NOT |
| be communicated by proxies over further connections. |  | be communicated by proxies over further connections. |
| The Connection header's value has the following grammar: |  | The Connection header field's value has the following grammar: |
| Connection = "Connection" ":" OWS Connection-v |  | Connection = "Connection" ":" OWS Connection-v |
| Connection-v = 1#connection-token |  | Connection-v = 1#connection-token |
| connection-token = token |  | connection-token = token |
| HTTP/1.1 proxies MUST parse the Connection header field before a |  | HTTP/1.1 proxies MUST parse the Connection header field before a |
| message is forwarded and, for each connection-token in this field, |  | message is forwarded and, for each connection-token in this field, |
| remove any header field(s) from the message with the same name as the |  | remove any header field(s) from the message with the same name as the |
| connection-token. Connection options are signaled by the presence of |  | connection-token. Connection options are signaled by the presence of |
| a connection-token in the Connection header field, not by any |  | a connection-token in the Connection header field, not by any |
| corresponding additional header field(s), since the additional header |  | corresponding additional header field(s), since the additional header |
| field might not be sent if there are no parameters associated with |  | field might not be sent if there are no parameters associated with |
| that connection option. |  | that connection option. |
| Message headers listed in the Connection header MUST NOT include end- |  | Message header fields listed in the Connection header field MUST NOT |
| to-end headers, such as Cache-Control. |  | include end-to-end header fields, such as Cache-Control. |
| HTTP/1.1 defines the "close" connection option for the sender to |  | HTTP/1.1 defines the "close" connection option for the sender to |
| signal that the connection will be closed after completion of the |  | signal that the connection will be closed after completion of the |
| response. For example, |  | response. For example, |
| Connection: close |  | Connection: close |
| in either the request or the response header fields indicates that |  | in either the request or the response header fields indicates that |
| the connection SHOULD NOT be considered "persistent" (Section 7.1) |  | the connection SHOULD NOT be considered "persistent" (Section 7.1) |
| after the current request/response is complete. |  | after the current request/response is complete. |
| An HTTP/1.1 client that does not support persistent connections MUST |  | An HTTP/1.1 client that does not support persistent connections MUST |
| include the "close" connection option in every request message. |  | include the "close" connection option in every request message. |
| An HTTP/1.1 server that does not support persistent connections MUST |  | An HTTP/1.1 server that does not support persistent connections MUST |
| include the "close" connection option in every response message that |  | include the "close" connection option in every response message that |
| does not have a 1xx (Informational) status code. |  | does not have a 1xx (Informational) status code. |
| A system receiving an HTTP/1.0 (or lower-version) message that |  | A system receiving an HTTP/1.0 (or lower-version) message that |
| includes a Connection header MUST, for each connection-token in this |  | includes a Connection header field MUST, for each connection-token in |
| field, remove and ignore any header field(s) from the message with |  | this field, remove and ignore any header field(s) from the message |
| the same name as the connection-token. This protects against |  | with the same name as the connection-token. This protects against |
| mistaken forwarding of such header fields by pre-HTTP/1.1 proxies. |  | mistaken forwarding of such header fields by pre-HTTP/1.1 proxies. |
| See Appendix B.2. |  | See Appendix B.2. |
| 9.2. Content-Length |  | 9.2. Content-Length |
| The "Content-Length" header field indicates the size of the message- |  | The "Content-Length" header field indicates the size of the message- |
| body, in decimal number of octets, for any message other than a |  | body, in decimal number of octets, for any message other than a |
| response to the HEAD method or a response with a status code of 304. |  | response to the HEAD method or a response with a status code of 304. |
| In the case of responses to the HEAD method, it indicates the size of |  | In the case of responses to the HEAD method, it indicates the size of |
| the payload body (not including any potential transfer-coding) that |  | the payload body (not including any potential transfer-coding) that |
| skipping to change at page 51, line 51 |  | skipping to change at page 52, line 7 |
| (Internal Server Error) or 503 (Service Unavailable), and it is |  | (Internal Server Error) or 503 (Service Unavailable), and it is |
| inconvenient or impossible to generate a valid Date. |  | inconvenient or impossible to generate a valid Date. |
| 3. If the server does not have a clock that can provide a reasonable |  | 3. If the server does not have a clock that can provide a reasonable |
| approximation of the current time, its responses MUST NOT include |  | approximation of the current time, its responses MUST NOT include |
| a Date header field. In this case, the rules in Section 9.3.1 |  | a Date header field. In this case, the rules in Section 9.3.1 |
| MUST be followed. |  | MUST be followed. |
| A received message that does not have a Date header field MUST be |  | A received message that does not have a Date header field MUST be |
| assigned one by the recipient if the message will be cached by that |  | assigned one by the recipient if the message will be cached by that |
| recipient or gatewayed via a protocol which requires a Date. An HTTP |  | recipient or gatewayed via a protocol which requires a Date. |
| implementation without a clock MUST NOT cache responses without |  |  |
| revalidating them on every use. An HTTP cache, especially a shared |  |  |
| cache, SHOULD use a mechanism, such as NTP [RFC1305], to synchronize |  |  |
| its clock with a reliable external standard. |  |  |
| Clients SHOULD only send a Date header field in messages that include |  | Clients can use the Date header field as well; in order to keep |
| a payload, as is usually the case for PUT and POST requests, and even |  | request messages small, they are advised not to include it when it |
| then it is optional. A client without a clock MUST NOT send a Date |  | doesn't convey any useful information (as it is usually the case for |
| header field in a request. |  | requests that do not contain a payload). |
| The HTTP-date sent in a Date header SHOULD NOT represent a date and |  | The HTTP-date sent in a Date header field SHOULD NOT represent a date |
| time subsequent to the generation of the message. It SHOULD |  | and time subsequent to the generation of the message. It SHOULD |
| represent the best available approximation of the date and time of |  | represent the best available approximation of the date and time of |
| message generation, unless the implementation has no means of |  | message generation, unless the implementation has no means of |
| generating a reasonably accurate date and time. In theory, the date |  | generating a reasonably accurate date and time. In theory, the date |
| ought to represent the moment just before the payload is generated. |  | ought to represent the moment just before the payload is generated. |
| In practice, the date can be generated at any time during the message |  | In practice, the date can be generated at any time during the message |
| origination without affecting its semantic value. |  | origination without affecting its semantic value. |
| 9.3.1. Clockless Origin Server Operation |  | 9.3.1. Clockless Origin Server Operation |
| Some origin server implementations might not have a clock available. |  | Some origin server implementations might not have a clock available. |
| skipping to change at page 55, line 36 |  | skipping to change at page 55, line 34 |
| Transfer-codings are defined in Section 6.2. An example is: |  | Transfer-codings are defined in Section 6.2. An example is: |
| Transfer-Encoding: chunked |  | Transfer-Encoding: chunked |
| If multiple encodings have been applied to a representation, the |  | If multiple encodings have been applied to a representation, the |
| transfer-codings MUST be listed in the order in which they were |  | transfer-codings MUST be listed in the order in which they were |
| applied. Additional information about the encoding parameters MAY be |  | applied. Additional information about the encoding parameters MAY be |
| provided by other header fields not defined by this specification. |  | provided by other header fields not defined by this specification. |
| Many older HTTP/1.0 applications do not understand the Transfer- |  | Many older HTTP/1.0 applications do not understand the Transfer- |
| Encoding header. |  | Encoding header field. |
| 9.8. Upgrade |  | 9.8. Upgrade |
| The "Upgrade" general-header field allows the client to specify what |  | The "Upgrade" general-header field allows the client to specify what |
| additional communication protocols it would like to use, if the |  | additional communication protocols it would like to use, if the |
| server chooses to switch protocols. Additionally, the server MUST |  | server chooses to switch protocols. Additionally, the server MUST |
| use the Upgrade header field within a 101 (Switching Protocols) |  | use the Upgrade header field within a 101 (Switching Protocols) |
| response to indicate which protocol(s) are being switched to. |  | response to indicate which protocol(s) are being switched to. |
| Upgrade = "Upgrade" ":" OWS Upgrade-v |  | Upgrade = "Upgrade" ":" OWS Upgrade-v |
| skipping to change at page 66, line 36 |  | skipping to change at page 66, line 36 |
| 13.1. Normative References |  | 13.1. Normative References |
| [ISO-8859-1] International Organization for Standardization, |  | [ISO-8859-1] International Organization for Standardization, |
| "Information technology -- 8-bit single-byte coded |  | "Information technology -- 8-bit single-byte coded |
| graphic character sets -- Part 1: Latin alphabet No. |  | graphic character sets -- Part 1: Latin alphabet No. |
| 1", ISO/IEC 8859-1:1998, 1998. |  | 1", ISO/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., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., |
| Ed., and J. Reschke, Ed., "HTTP/1.1, part 2: Message |  | Ed., and J. Reschke, Ed., "HTTP/1.1, part 2: Message |
| Semantics", draft-ietf-httpbis-p2-semantics-11 (work in |  | Semantics", draft-ietf-httpbis-p2-semantics-12 (work in |
| progress), August 2010. |  | progress), October 2010. |
| [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., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., |
| Ed., and J. Reschke, Ed., "HTTP/1.1, part 3: Message |  | Ed., and J. Reschke, Ed., "HTTP/1.1, part 3: Message |
| Payload and Content Negotiation", |  | Payload and Content Negotiation", |
| draft-ietf-httpbis-p3-payload-11 (work in progress), |  | draft-ietf-httpbis-p3-payload-12 (work in progress), |
| August 2010. |  | October 2010. |
| [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., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., |
| Ed., Nottingham, M., Ed., and J. Reschke, Ed., |  | Ed., Nottingham, M., Ed., and J. Reschke, Ed., |
| "HTTP/1.1, part 6: Caching", |  | "HTTP/1.1, part 6: Caching", |
| draft-ietf-httpbis-p6-cache-11 (work in progress), |  | draft-ietf-httpbis-p6-cache-12 (work in progress), |
| August 2010. |  | October 2010. |
| [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data |  | [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data |
| Format Specification version 3.3", RFC 1950, May 1996. |  | Format Specification version 3.3", RFC 1950, May 1996. |
| RFC 1950 is an Informational RFC, thus it might be less |  | RFC 1950 is an Informational RFC, thus it might be less |
| stable than this specification. On the other hand, |  | stable than this specification. On the other hand, |
| this downward reference was present since the |  | this downward reference was present since the |
| publication of RFC 2068 in 1997 ([RFC2068]), therefore |  | publication of RFC 2068 in 1997 ([RFC2068]), therefore |
| it is unlikely to cause problems in practice. See also |  | it is unlikely to cause problems in practice. See also |
| [BCP97]. |  | [BCP97]. |
| skipping to change at page 67, line 41 |  | skipping to change at page 67, line 41 |
| this downward reference was present since the |  | this downward reference was present since the |
| publication of RFC 2068 in 1997 ([RFC2068]), therefore |  | publication of RFC 2068 in 1997 ([RFC2068]), therefore |
| it is unlikely to cause problems in practice. See also |  | it is unlikely to cause problems in practice. See also |
| [BCP97]. |  | [BCP97]. |
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |  | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |
| Requirement Levels", BCP 14, RFC 2119, March 1997. |  | Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, |  | [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, |
| "Uniform Resource Identifier (URI): Generic Syntax", |  | "Uniform Resource Identifier (URI): Generic Syntax", |
| RFC 3986, STD 66, January 2005. |  | STD 66, RFC 3986, January 2005. |
| [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for |  | [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for |
| Syntax Specifications: ABNF", STD 68, RFC 5234, |  | Syntax Specifications: ABNF", STD 68, RFC 5234, |
| January 2008. |  | January 2008. |
| [USASCII] American National Standards Institute, "Coded Character |  | [USASCII] American National Standards Institute, "Coded Character |
| Set -- 7-bit American Standard Code for Information |  | Set -- 7-bit American Standard Code for Information |
| Interchange", ANSI X3.4, 1986. |  | Interchange", ANSI X3.4, 1986. |
| 13.2. Informative References |  | 13.2. Informative References |
| skipping to change at page 68, line 33 |  | skipping to change at page 68, line 33 |
| [Pad1995] Padmanabhan, V. and J. Mogul, "Improving HTTP Latency", |  | [Pad1995] Padmanabhan, V. and J. Mogul, "Improving HTTP Latency", |
| Computer Networks and ISDN Systems v. 28, pp. 25-35, |  | Computer Networks and ISDN Systems v. 28, pp. 25-35, |
| December 1995, |  | December 1995, |
| <http://portal.acm.org/citation.cfm?id=219094>. |  | <http://portal.acm.org/citation.cfm?id=219094>. |
| [RFC1123] Braden, R., "Requirements for Internet Hosts - |  | [RFC1123] Braden, R., "Requirements for Internet Hosts - |
| Application and Support", STD 3, RFC 1123, |  | Application and Support", STD 3, RFC 1123, |
| October 1989. |  | October 1989. |
| [RFC1305] Mills, D., "Network Time Protocol (Version 3) |  |  |
| Specification, Implementation", RFC 1305, March 1992. |  |  |
| [RFC1900] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", |  | [RFC1900] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", |
| RFC 1900, February 1996. |  | RFC 1900, February 1996. |
| [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, |  | [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, |
| "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, |  | "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, |
| May 1996. |  | May 1996. |
| [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet |  | [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet |
| Mail Extensions (MIME) Part One: Format of Internet |  | Mail Extensions (MIME) Part One: Format of Internet |
| Message Bodies", RFC 2045, November 1996. |  | Message Bodies", RFC 2045, November 1996. |
| skipping to change at page 70, line 19 |  | skipping to change at page 70, line 19 |
| implementation. We therefore recommend that operational applications |  | implementation. We therefore recommend that operational applications |
| be tolerant of deviations whenever those deviations can be |  | be tolerant of deviations whenever those deviations can be |
| interpreted unambiguously. |  | interpreted unambiguously. |
| Clients SHOULD be tolerant in parsing the Status-Line and servers |  | Clients SHOULD be tolerant in parsing the Status-Line and servers |
| SHOULD be tolerant when parsing the Request-Line. In particular, |  | SHOULD be tolerant when parsing the Request-Line. In particular, |
| they SHOULD accept any amount of WSP characters between fields, even |  | they SHOULD accept any amount of WSP characters between fields, even |
| though only a single SP is required. |  | though only a single SP is required. |
| The line terminator for header fields is the sequence CRLF. However, |  | The line terminator for header fields is the sequence CRLF. However, |
| we recommend that applications, when parsing such headers, recognize |  | we recommend that applications, when parsing such headers fields, |
| a single LF as a line terminator and ignore the leading CR. |  | recognize a single LF as a line terminator and ignore the leading CR. |
| The character set of a representation SHOULD be labeled as the lowest |  | The character set of a representation SHOULD be labeled as the lowest |
| common denominator of the character codes used within that |  | common denominator of the character codes used within that |
| representation, with the exception that not labeling the |  | representation, with the exception that not labeling the |
| representation is preferred over labeling the representation with the |  | representation is preferred over labeling the representation with the |
| labels US-ASCII or ISO-8859-1. See [Part3]. |  | labels US-ASCII or ISO-8859-1. See [Part3]. |
| Additional rules for requirements on parsing and encoding of dates |  | Additional rules for requirements on parsing and encoding of dates |
| and other potential problems with date encodings include: |  | and other potential problems with date encodings include: |
| skipping to change at page 70, line 48 |  | skipping to change at page 70, line 48 |
| o An HTTP/1.1 implementation MAY internally represent a parsed |  | o An HTTP/1.1 implementation MAY internally represent a parsed |
| Expires date as earlier than the proper value, but MUST NOT |  | Expires date as earlier than the proper value, but MUST NOT |
| internally represent a parsed Expires date as later than the |  | internally represent a parsed Expires date as later than the |
| proper value. |  | proper value. |
| o All expiration-related calculations MUST be done in GMT. The |  | o All expiration-related calculations MUST be done in GMT. The |
| local time zone MUST NOT influence the calculation or comparison |  | local time zone MUST NOT influence the calculation or comparison |
| of an age or expiration time. |  | of an age or expiration time. |
| o If an HTTP header incorrectly carries a date value with a time |  | o If an HTTP header field incorrectly carries a date value with a |
| zone other than GMT, it MUST be converted into GMT using the most |  | time zone other than GMT, it MUST be converted into GMT using the |
| conservative possible conversion. |  | most conservative possible conversion. |
| Appendix B. Compatibility with Previous Versions |  | Appendix B. Compatibility with Previous Versions |
| HTTP has been in use by the World-Wide Web global information |  | HTTP has been in use by the World-Wide Web global information |
| initiative since 1990. The first version of HTTP, later referred to |  | initiative since 1990. The first version of HTTP, later referred to |
| as HTTP/0.9, was a simple protocol for hypertext data transfer across |  | as HTTP/0.9, was a simple protocol for hypertext data transfer across |
| the Internet with only a single method and no metadata. HTTP/1.0, as |  | the Internet with only a single method and no metadata. HTTP/1.0, as |
| defined by [RFC1945], added a range of request methods and MIME-like |  | defined by [RFC1945], added a range of request methods and MIME-like |
| messaging that could include metadata about the data transferred and |  | messaging that could include metadata about the data transferred and |
| modifiers on the request/response semantics. However, HTTP/1.0 did |  | modifiers on the request/response semantics. However, HTTP/1.0 did |
| skipping to change at page 72, line 9 |  | skipping to change at page 72, line 9 |
| B.1. Changes from HTTP/1.0 |  | B.1. Changes from HTTP/1.0 |
| This section summarizes major differences between versions HTTP/1.0 |  | This section summarizes major differences between versions HTTP/1.0 |
| and HTTP/1.1. |  | and HTTP/1.1. |
| B.1.1. Changes to Simplify Multi-homed Web Servers and Conserve IP |  | B.1.1. Changes to Simplify Multi-homed Web Servers and Conserve IP |
| Addresses |  | Addresses |
| The requirements that clients and servers support the Host request- |  | The requirements that clients and servers support the Host request- |
| header, report an error if the Host request-header (Section 9.4) is |  | header field (Section 9.4), report an error if it is missing from an |
| missing from an HTTP/1.1 request, and accept absolute URIs |  | HTTP/1.1 request, and accept absolute URIs (Section 4.1.2) are among |
| (Section 4.1.2) are among the most important changes defined by this |  | the most important changes defined by this specification. |
| specification. |  |  |
| Older HTTP/1.0 clients assumed a one-to-one relationship of IP |  | Older HTTP/1.0 clients assumed a one-to-one relationship of IP |
| addresses and servers; there was no other established mechanism for |  | addresses and servers; there was no other established mechanism for |
| distinguishing the intended server of a request than the IP address |  | distinguishing the intended server of a request than the IP address |
| to which that request was directed. The changes outlined above will |  | to which that request was directed. The changes outlined above will |
| allow the Internet, once older HTTP clients are no longer common, to |  | allow the Internet, once older HTTP clients are no longer common, to |
| support multiple Web sites from a single IP address, greatly |  | support multiple Web sites from a single IP address, greatly |
| simplifying large operational Web servers, where allocation of many |  | simplifying large operational Web servers, where allocation of many |
| IP addresses to a single host has created serious problems. The |  | IP addresses to a single host has created serious problems. The |
| Internet will also be able to recover the IP addresses that have been |  | Internet will also be able to recover the IP addresses that have been |
| allocated for the sole purpose of allowing special-purpose domain |  | allocated for the sole purpose of allowing special-purpose domain |
| names to be used in root-level HTTP URLs. Given the rate of growth |  | names to be used in root-level HTTP URLs. Given the rate of growth |
| of the Web, and the number of servers already deployed, it is |  | of the Web, and the number of servers already deployed, it is |
| extremely important that all implementations of HTTP (including |  | extremely important that all implementations of HTTP (including |
| updates to existing HTTP/1.0 applications) correctly implement these |  | updates to existing HTTP/1.0 applications) correctly implement these |
| requirements: |  | requirements: |
| o Both clients and servers MUST support the Host request-header. |  | o Both clients and servers MUST support the Host request-header |
|  |  | field. |
| o A client that sends an HTTP/1.1 request MUST send a Host header. |  | o A client that sends an HTTP/1.1 request MUST send a Host header |
|  |  | field. |
| o Servers MUST report a 400 (Bad Request) error if an HTTP/1.1 |  | o Servers MUST report a 400 (Bad Request) error if an HTTP/1.1 |
| request does not include a Host request-header. |  | request does not include a Host request-header field. |
| o Servers MUST accept absolute URIs. |  | o Servers MUST accept absolute URIs. |
| B.2. Compatibility with HTTP/1.0 Persistent Connections |  | B.2. Compatibility with HTTP/1.0 Persistent Connections |
| Some clients and servers might wish to be compatible with some |  | Some clients and servers might wish to be compatible with some |
| previous implementations of persistent connections in HTTP/1.0 |  | previous implementations of persistent connections in HTTP/1.0 |
| clients and servers. Persistent connections in HTTP/1.0 are |  | clients and servers. Persistent connections in HTTP/1.0 are |
| explicitly negotiated as they are not the default behavior. HTTP/1.0 |  | explicitly negotiated as they are not the default behavior. HTTP/1.0 |
| experimental implementations of persistent connections are faulty, |  | experimental implementations of persistent connections are faulty, |
| skipping to change at page 73, line 15 |  | skipping to change at page 73, line 16 |
| However, talking to proxies is the most important use of persistent |  | However, talking to proxies is the most important use of persistent |
| connections, so that prohibition is clearly unacceptable. Therefore, |  | connections, so that prohibition is clearly unacceptable. Therefore, |
| we need some other mechanism for indicating a persistent connection |  | we need some other mechanism for indicating a persistent connection |
| is desired, which is safe to use even when talking to an old proxy |  | is desired, which is safe to use even when talking to an old proxy |
| that ignores Connection. Persistent connections are the default for |  | that ignores Connection. Persistent connections are the default for |
| HTTP/1.1 messages; we introduce a new keyword (Connection: close) for |  | HTTP/1.1 messages; we introduce a new keyword (Connection: close) for |
| declaring non-persistence. See Section 9.1. |  | declaring non-persistence. See Section 9.1. |
| The original HTTP/1.0 form of persistent connections (the Connection: |  | The original HTTP/1.0 form of persistent connections (the Connection: |
| Keep-Alive and Keep-Alive header) is documented in Section 19.7.1 of |  | Keep-Alive and Keep-Alive header field) is documented in Section |
| [RFC2068]. |  | 19.7.1 of [RFC2068]. |
| B.3. Changes from RFC 2616 |  | B.3. Changes from RFC 2616 |
| Empty list elements in list productions have been deprecated. |  | Empty list elements in list productions have been deprecated. |
| (Section 1.2.1) |  | (Section 1.2.1) |
| Rules about implicit linear whitespace between certain grammar |  | Rules about implicit linear whitespace between certain grammar |
| productions have been removed; now it's only allowed when |  | productions have been removed; now it's only allowed when |
| specifically pointed out in the ABNF. The NUL character is no longer |  | specifically pointed out in the ABNF. The NUL character is no longer |
| allowed in comment and quoted-string text. The quoted-pair rule no |  | allowed in comment and quoted-string text. The quoted-pair rule no |
| longer allows escaping control characters other than HTAB. Non-ASCII |  | longer allows escaping control characters other than HTAB. Non-ASCII |
| content in header fields and reason phrase has been obsoleted and |  | content in header fields and reason phrase has been obsoleted and |
| made opaque (the TEXT rule was removed) (Section 1.2.2) |  | made opaque (the TEXT rule was removed) (Section 1.2.2) |
| Clarify that HTTP-Version is case sensitive. (Section 2.5) |  | Clarify that HTTP-Version is case sensitive. (Section 2.5) |
| Remove reference to non-existent identity transfer-coding value |  |  |
| tokens. (Sections 6.2 and 3.3) |  |  |
| Require that invalid whitespace around field-names be rejected. |  | Require that invalid whitespace around field-names be rejected. |
| (Section 3.2) |  | (Section 3.2) |
| Update use of abs_path production from RFC1808 to the path-absolute + |  | Require recipients to handle bogus Content-Length header fields as |
| query components of RFC3986. (Section 4.1.2) |  | errors. (Section 3.3) |
|  |  | Remove reference to non-existent identity transfer-coding value |
|  |  | tokens. (Sections 3.3 and 6.2) |
|  |  | Update use of abs_path production from RFC 1808 to the path-absolute |
|  |  | + query components of RFC 3986. (Section 4.1.2) |
| 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. Furthermore disallowed line |  | octets in the chunk header and trailer. Furthermore disallowed line |
| folding in chunk extensions. (Section 6.2.1) |  | folding in chunk extensions. (Section 6.2.1) |
| Remove hard limit of two connections per server. (Section 7.1.4) |  | Remove hard limit of two connections per server. (Section 7.1.4) |
| Clarify exactly when close connection options must be sent. |  | Clarify exactly when close connection options must be sent. |
| (Section 9.1) |  | (Section 9.1) |
| Appendix C. Collected ABNF |  | Appendix C. Collected ABNF |
| BWS = OWS |  | BWS = OWS |
| Cache-Control = <Cache-Control, defined in [Part6], Section 3.4> |  | Cache-Control = <Cache-Control, defined in [Part6], Section 3.4> |
| Chunked-Body = *chunk last-chunk trailer-part CRLF |  | Chunked-Body = *chunk last-chunk trailer-part CRLF |
| Connection = "Connection:" OWS Connection-v |  | Connection = "Connection:" OWS Connection-v |
| Connection-v = *( "," OWS ) connection-token *( OWS "," [ OWS |  | Connection-v = *( "," OWS ) connection-token *( OWS "," [ OWS |
| connection-token ] ) |  | connection-token ] ) |
| Content-Length = "Content-Length:" OWS 1*Content-Length-v |  | Content-Length = "Content-Length:" OWS 1*Content-Length-v |
| Content-Length-v = 1*DIGIT |  | Content-Length-v = 1*DIGIT |
| skipping to change at page 78, line 24 |  | skipping to change at page 78, line 28 |
| ; general-header defined but not used |  | ; general-header defined but not used |
| ; http-URI defined but not used |  | ; http-URI defined but not used |
| ; https-URI defined but not used |  | ; https-URI defined but not used |
| ; partial-URI defined but not used |  | ; partial-URI defined but not used |
| ; request-header defined but not used |  | ; request-header defined but not used |
| ; response-header defined but not used |  | ; response-header defined but not used |
| ; special defined but not used |  | ; special defined but not used |
| 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 RFC 2616 |
| Extracted relevant partitions from [RFC2616]. |  | Extracted relevant partitions from [RFC2616]. |
| D.2. Since draft-ietf-httpbis-p1-messaging-00 |  | D.2. Since draft-ietf-httpbis-p1-messaging-00 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/1>: "HTTP Version |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/1>: "HTTP Version |
| should be case sensitive" |  | should be case sensitive" |
| (<http://purl.org/NET/http-errata#verscase>) |  | (<http://purl.org/NET/http-errata#verscase>) |
| skipping to change at page 80, line 42 |  | skipping to change at page 80, line 43 |
| "host) -- these will have to be updated when switching over to |  | "host) -- these will have to be updated when switching over to |
| RFC3986. |  | RFC3986. |
| o Synchronize core rules with RFC5234. |  | o Synchronize core rules with RFC5234. |
| o Get rid of prose rules that span multiple lines. |  | o Get rid of prose rules that span multiple lines. |
| o Get rid of unused rules LOALPHA and UPALPHA. |  | o Get rid of unused rules LOALPHA and UPALPHA. |
| 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 field. |
| 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". |
| D.4. Since draft-ietf-httpbis-p1-messaging-02 |  | D.4. Since draft-ietf-httpbis-p1-messaging-02 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/51>: "HTTP-date vs. |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/51>: "HTTP-date vs. |
| rfc1123-date" |  | rfc1123-date" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/64>: "WS in quoted- |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/64>: "WS in quoted- |
| pair" |  | pair" |
| Ongoing work on IANA Message Header Registration |  | Ongoing work on IANA Message Header Field Registration |
| (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>): |  | (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>): |
| o Reference RFC 3984, and update header registrations for headers |  | o Reference RFC 3984, and update header field registrations for |
| defined in this document. |  | headers defined in this document. |
| Ongoing work on ABNF conversion |  | Ongoing work on ABNF conversion |
| (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |  | (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |
| o Replace string literals when the string really is case-sensitive |  | o Replace string literals when the string really is case-sensitive |
| (HTTP-Version). |  | (HTTP-Version). |
| D.5. Since draft-ietf-httpbis-p1-messaging-03 |  | D.5. Since draft-ietf-httpbis-p1-messaging-03 |
| Closed issues: |  | Closed issues: |
| skipping to change at page 82, line 34 |  | skipping to change at page 82, line 34 |
| o Use "/" instead of "|" for alternatives. |  | o Use "/" instead of "|" for alternatives. |
| o Get rid of RFC822 dependency; use RFC5234 plus extensions instead. |  | o Get rid of RFC822 dependency; use RFC5234 plus extensions instead. |
| o Only reference RFC 5234's core rules. |  | o Only reference RFC 5234's core rules. |
| o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional |  | o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional |
| whitespace ("OWS") and required whitespace ("RWS"). |  | whitespace ("OWS") and required whitespace ("RWS"). |
| o Rewrite ABNFs to spell out whitespace rules, factor out header |  | o Rewrite ABNFs to spell out whitespace rules, factor out header |
| value format definitions. |  | field value format definitions. |
| D.7. Since draft-ietf-httpbis-p1-messaging-05 |  | D.7. Since draft-ietf-httpbis-p1-messaging-05 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/30>: "Header LWS" |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/30>: "Header LWS" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/52>: "Sort 1.3 |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/52>: "Sort 1.3 |
| Terminology" |  | Terminology" |
| skipping to change at page 83, line 30 |  | skipping to change at page 83, line 30 |
| o Rewrite definition of list rules, deprecate empty list elements. |  | o Rewrite definition of list rules, deprecate empty list elements. |
| o Add appendix containing collected and expanded ABNF. |  | o Add appendix containing collected and expanded ABNF. |
| Other changes: |  | Other changes: |
| o Rewrite introduction; add mostly new Architecture Section. |  | o Rewrite introduction; add mostly new Architecture Section. |
| o Move definition of quality values from Part 3 into Part 1; make TE |  | o Move definition of quality values from Part 3 into Part 1; make TE |
| request header grammar independent of accept-params (defined in |  | request header field grammar independent of accept-params (defined |
| Part 3). |  | in Part 3). |
| D.8. Since draft-ietf-httpbis-p1-messaging-06 |  | D.8. Since draft-ietf-httpbis-p1-messaging-06 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/161>: "base for |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/161>: "base for |
| numeric protocol elements" |  | numeric protocol elements" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/162>: "comment ABNF" |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/162>: "comment ABNF" |
| skipping to change at page 86, line 10 |  | skipping to change at page 86, line 10 |
| entity / representation / variant terminology" |  | entity / representation / variant terminology" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider |
| removing the 'changes from 2068' sections" |  | removing the 'changes from 2068' sections" |
| Partly resolved issues: |  | Partly resolved issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/159>: "HTTP(s) URI |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/159>: "HTTP(s) URI |
| scheme definitions" |  | scheme definitions" |
|  |  | D.13. Since draft-ietf-httpbis-p1-messaging-11 |
|  |  | Closed issues: |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/193>: "Trailer |
|  |  | requirements" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/204>: "Text about |
|  |  | clock requirement for caches belongs in p6" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/221>: "effective |
|  |  | request URI: handling of missing host in HTTP/1.0" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/248>: "confusing |
|  |  | Date requirements for clients" |
|  |  | Partly resolved issues: |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/95>: "Handling |
|  |  | multiple Content-Length headers" |
| Index |  | Index |
| A |  | A |
|  |  | absolute-URI form (of request-target) 27 |
| application/http Media Type 61 |  | application/http Media Type 61 |
|  |  | asterisk form (of request-target) 27 |
|  |  | authority form (of request-target) 27 |
| B |  | B |
| browser 10 |  | browser 10 |
| C |  | C |
| cache 13 |  | cache 13 |
| cacheable 14 |  | cacheable 14 |
| chunked (Coding Format) 35 |  | chunked (Coding Format) 35 |
| client 10 |  | client 10 |
| Coding Format |  | Coding Format |
| skipping to change at page 90, line 6 |  | skipping to change at page 90, line 29 |
| application/http 61 |  | application/http 61 |
| message/http 59 |  | message/http 59 |
| message 11 |  | message 11 |
| message/http Media Type 59 |  | message/http Media Type 59 |
| O |  | O |
| origin server 10 |  | origin server 10 |
| outbound 12 |  | outbound 12 |
| P |  | P |
|  |  | path-absolute form (of request-target) 27 |
| proxy 12 |  | proxy 12 |
| R |  | R |
| request 11 |  | request 11 |
| resource 16 |  | resource 16 |
| response 11 |  | response 11 |
| reverse proxy 13 |  | reverse proxy 13 |
| S |  | S |
| server 10 |  | server 10 |
End of changes. 75 change blocks.
| 141 lines changed or deleted |  | 168 lines changed or added |
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/