Changeset 1178 for draft-ietf-httpbis/latest
- Timestamp:
- 14/03/11 05:07:18 (11 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1177 r1178 395 395 <link rel="Chapter" href="#rfc.section.13" title="13 References"> 396 396 <link rel="Appendix" title="A Tolerant Applications" href="#rfc.section.A"> 397 <link rel="Appendix" title="B Compatibility with Previous Versions" href="#rfc.section.B">397 <link rel="Appendix" title="B HTTP Version History" href="#rfc.section.B"> 398 398 <link rel="Appendix" title="C Collected ABNF" href="#rfc.section.C"> 399 399 <link rel="Appendix" title="D Change Log (to be removed by RFC Editor before publication)" href="#rfc.section.D"> … … 685 685 <li><a href="#rfc.authors">Authors' Addresses</a></li> 686 686 <li>A. <a href="#tolerant.applications">Tolerant Applications</a></li> 687 <li>B. <a href="#compatibility"> Compatibility with Previous Versions</a><ul>687 <li>B. <a href="#compatibility">HTTP Version History</a><ul> 688 688 <li>B.1 <a href="#changes.from.1.0">Changes from HTTP/1.0</a><ul> 689 <li>B.1.1 <a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses">Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses</a></li> 689 <li>B.1.1 <a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses">Multi-homed Web Servers</a></li> 690 <li>B.1.2 <a href="#compatibility.with.http.1.0.persistent.connections">Keep-Alive Connections</a></li> 690 691 </ul> 691 692 </li> 692 <li>B.2 <a href="#compatibility.with.http.1.0.persistent.connections">Compatibility with HTTP/1.0 Persistent Connections</a></li> 693 <li>B.3 <a href="#changes.from.rfc.2616">Changes from RFC 2616</a></li> 693 <li>B.2 <a href="#changes.from.rfc.2616">Changes from RFC 2616</a></li> 694 694 </ul> 695 695 </li> … … 1195 1195 stream at the beginning of a message and receives a CRLF first, it <em class="bcp14">SHOULD</em> ignore the CRLF. 1196 1196 </p> 1197 <p id="rfc.section.3.1.p.2">Some old HTTP/1.0 client implementations generatean extra CRLF after a POST request as a lame workaround for some early server1197 <p id="rfc.section.3.1.p.2">Some old HTTP/1.0 client implementations send an extra CRLF after a POST request as a lame workaround for some early server 1198 1198 applications that failed to read message-body content that was not terminated by a line-ending. An HTTP/1.1 client <em class="bcp14">MUST NOT</em> preface or follow a request with an extra CRLF. If terminating the request message-body with a line-ending is desired, then 1199 1199 the client <em class="bcp14">MUST</em> include the terminating CRLF octets as part of the message-body length. … … 1483 1483 field. 1484 1484 </p> 1485 <p id="rfc.section.4.2.p.2">An origin server that does not allow resources to differ by the requested host <em class="bcp14">MAY</em> ignore the Host header field value when determining the resource identified by an HTTP/1.1 request. (But see <a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" title=" Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses">Appendix B.1.1</a> for other requirements on Host support in HTTP/1.1.)1485 <p id="rfc.section.4.2.p.2">An origin server that does not allow resources to differ by the requested host <em class="bcp14">MAY</em> ignore the Host header field value when determining the resource identified by an HTTP/1.1 request. (But see <a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" title="Multi-homed Web Servers">Appendix B.1.1</a> for other requirements on Host support in HTTP/1.1.) 1486 1486 </p> 1487 1487 <p id="rfc.section.4.2.p.3">An origin server that does differentiate resources based on the host requested (sometimes referred to as virtual hosts or … … 1866 1866 for the connection. 1867 1867 </p> 1868 <p id="rfc.section.7.1.2.1.p.4">Clients and servers <em class="bcp14">SHOULD NOT</em> assume that a persistent connection is maintained for HTTP versions less than 1.1 unless it is explicitly signaled. See <a href="#compatibility.with.http.1.0.persistent.connections" title=" Compatibility with HTTP/1.0 Persistent Connections">Appendix B.2</a> for more information on backward compatibility with HTTP/1.0 clients.1868 <p id="rfc.section.7.1.2.1.p.4">Clients and servers <em class="bcp14">SHOULD NOT</em> assume that a persistent connection is maintained for HTTP versions less than 1.1 unless it is explicitly signaled. See <a href="#compatibility.with.http.1.0.persistent.connections" title="Keep-Alive Connections">Appendix B.1.2</a> for more information on backward compatibility with HTTP/1.0 clients. 1869 1869 </p> 1870 1870 <p id="rfc.section.7.1.2.1.p.5">In order to remain persistent, all messages on the connection <em class="bcp14">MUST</em> have a self-defined message length (i.e., one not defined by closure of the connection), as described in <a href="#message.body" title="Message Body">Section 3.3</a>. … … 2212 2212 message that contains more than one Host header field or a Host header field with an invalid field-value. 2213 2213 </p> 2214 <p id="rfc.section.9.4.p.10">See Sections <a href="#the.resource.identified.by.a.request" title="The Resource Identified by a Request">4.2</a> and <a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" title=" Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses">B.1.1</a> for other requirements relating to Host.2214 <p id="rfc.section.9.4.p.10">See Sections <a href="#the.resource.identified.by.a.request" title="The Resource Identified by a Request">4.2</a> and <a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" title="Multi-homed Web Servers">B.1.1</a> for other requirements relating to Host. 2215 2215 </p> 2216 2216 <div id="rfc.iref.t.5"></div> … … 3001 3001 </li> 3002 3002 </ul> 3003 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="compatibility" href="#compatibility"> Compatibility with Previous Versions</a></h1>3003 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="compatibility" href="#compatibility">HTTP Version History</a></h1> 3004 3004 <p id="rfc.section.B.p.1">HTTP has been in use by the World-Wide Web global information initiative since 1990. The first version of HTTP, later referred 3005 3005 to as HTTP/0.9, was a simple protocol for hypertext data transfer across the Internet with only a single request method (GET) … … 3015 3015 </p> 3016 3016 <p id="rfc.section.B.p.3">It is beyond the scope of a protocol specification to mandate compliance with previous versions. HTTP/1.1 was deliberately 3017 designed, however, to make supporting previous versions easy. It is worth noting that, at the time of composing this specification, 3018 we would expect general-purpose HTTP/1.1 servers to: 3019 </p> 3020 <ul> 3021 <li>understand any valid request in the format of HTTP/1.0 and 1.1;</li> 3022 <li>respond appropriately with a message in the same major version used by the client.</li> 3023 </ul> 3024 <p id="rfc.section.B.p.4">And we would expect HTTP/1.1 clients to: </p> 3025 <ul> 3026 <li>understand any valid response in the format of HTTP/1.0 or 1.1.</li> 3027 </ul> 3028 <p id="rfc.section.B.p.5">For most implementations of HTTP/1.0, each connection is established by the client prior to the request and closed by the 3029 server after sending the response. Some implementations implement the Keep-Alive version of persistent connections described 3030 in <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.8"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>. 3017 designed, however, to make supporting previous versions easy. We would expect a general-purpose HTTP/1.1 server to understand 3018 any valid request in the format of HTTP/1.0 and respond appropriately with an HTTP/1.1 message that only uses features understood 3019 (or safely ignored) by HTTP/1.0 clients. Likewise, would expect an HTTP/1.1 client to understand any valid HTTP/1.0 response. 3020 </p> 3021 <p id="rfc.section.B.p.4">Since HTTP/0.9 did not support header fields in a request, there is no mechanism for it to support name-based virtual hosts 3022 (selection of resource by inspection of the Host header field). Any server that implements name-based virtual hosts ought 3023 to disable support for HTTP/0.9. Most requests that appear to be HTTP/0.9 are, in fact, badly constructed HTTP/1.x requests 3024 wherein a buggy client failed to properly encode linear whitespace found in a URI reference and placed in the request-target. 3031 3025 </p> 3032 3026 <h2 id="rfc.section.B.1"><a href="#rfc.section.B.1">B.1</a> <a id="changes.from.1.0" href="#changes.from.1.0">Changes from HTTP/1.0</a></h2> 3033 3027 <p id="rfc.section.B.1.p.1">This section summarizes major differences between versions HTTP/1.0 and HTTP/1.1.</p> 3034 <h3 id="rfc.section.B.1.1"><a href="#rfc.section.B.1.1">B.1.1</a> <a id="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses"> Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses</a></h3>3035 <p id="rfc.section.B.1.1.p.1">The requirements that clients and servers support the Host header field (<a href="#header.host" id="rfc.xref.header.host.3" title="Host">Section 9.4</a>), report an error if it is missing from an HTTP/1.1 request, and accept absolute URIs (<a href="#request-target" title="request-target">Section 4.1.2</a>) are among the most important changes defined by this specification.3028 <h3 id="rfc.section.B.1.1"><a href="#rfc.section.B.1.1">B.1.1</a> <a id="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses">Multi-homed Web Servers</a></h3> 3029 <p id="rfc.section.B.1.1.p.1">The requirements that clients and servers support the Host header field (<a href="#header.host" id="rfc.xref.header.host.3" title="Host">Section 9.4</a>), report an error if it is missing from an HTTP/1.1 request, and accept absolute URIs (<a href="#request-target" title="request-target">Section 4.1.2</a>) are among the most important changes defined by HTTP/1.1. 3036 3030 </p> 3037 3031 <p id="rfc.section.B.1.1.p.2">Older HTTP/1.0 clients assumed a one-to-one relationship of IP addresses and servers; there was no other established mechanism 3038 for distinguishing the intended server of a request than the IP address to which that request was directed. The changes outlined 3039 above will allow the Internet, once older HTTP clients are no longer common, to support multiple Web sites from a single IP 3040 address, greatly simplifying large operational Web servers, where allocation of many IP addresses to a single host has created 3041 serious problems. The Internet will also be able to recover the IP addresses that have been allocated for the sole purpose 3042 of allowing special-purpose domain names to be used. Given the rate of growth of the Web, and the number of servers already 3043 deployed, it is extremely important that all implementations of HTTP (including updates to existing HTTP/1.0 applications) 3044 correctly implement these requirements: 3045 </p> 3046 <ul> 3047 <li>Both clients and servers <em class="bcp14">MUST</em> support the Host header field. 3048 </li> 3049 <li>A client that sends an HTTP/1.1 request <em class="bcp14">MUST</em> send a Host header field. 3050 </li> 3051 <li>Servers <em class="bcp14">MUST</em> report a 400 (Bad Request) error if an HTTP/1.1 request does not include a Host header field. 3052 </li> 3053 <li>Servers <em class="bcp14">MUST</em> accept absolute URIs. 3054 </li> 3055 </ul> 3056 <h2 id="rfc.section.B.2"><a href="#rfc.section.B.2">B.2</a> <a id="compatibility.with.http.1.0.persistent.connections" href="#compatibility.with.http.1.0.persistent.connections">Compatibility with HTTP/1.0 Persistent Connections</a></h2> 3057 <p id="rfc.section.B.2.p.1">Some clients and servers might wish to be compatible with some previous implementations of persistent connections in HTTP/1.0 3032 for distinguishing the intended server of a request than the IP address to which that request was directed. The Host header 3033 field was introduced during the development of HTTP/1.1 and, though it was quickly implemented by most HTTP/1.0 browsers, 3034 additional requirements were placed on all HTTP/1.1 requests in order to ensure complete adoption. At the time of this writing, 3035 most HTTP-based services are dependent upon the Host header field for targeting requests. 3036 </p> 3037 <h3 id="rfc.section.B.1.2"><a href="#rfc.section.B.1.2">B.1.2</a> <a id="compatibility.with.http.1.0.persistent.connections" href="#compatibility.with.http.1.0.persistent.connections">Keep-Alive Connections</a></h3> 3038 <p id="rfc.section.B.1.2.p.1">For most implementations of HTTP/1.0, each connection is established by the client prior to the request and closed by the 3039 server after sending the response. However, some implementations implement the Keep-Alive version of persistent connections 3040 described in <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.8"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>. 3041 </p> 3042 <p id="rfc.section.B.1.2.p.2">Some clients and servers might wish to be compatible with some previous implementations of persistent connections in HTTP/1.0 3058 3043 clients and servers. Persistent connections in HTTP/1.0 are explicitly negotiated as they are not the default behavior. HTTP/1.0 3059 3044 experimental implementations of persistent connections are faulty, and the new facilities in HTTP/1.1 are designed to rectify … … 3063 3048 from using Keep-Alive when talking to proxies. 3064 3049 </p> 3065 <p id="rfc.section.B. 2.p.2">However, talking to proxies is the most important use of persistent connections, so that prohibition is clearly unacceptable.3050 <p id="rfc.section.B.1.2.p.3">However, talking to proxies is the most important use of persistent connections, so that prohibition is clearly unacceptable. 3066 3051 Therefore, we need some other mechanism for indicating a persistent connection is desired, which is safe to use even when 3067 3052 talking to an old proxy that ignores Connection. Persistent connections are the default for HTTP/1.1 messages; we introduce 3068 3053 a new keyword (Connection: close) for declaring non-persistence. See <a href="#header.connection" id="rfc.xref.header.connection.10" title="Connection">Section 9.1</a>. 3069 3054 </p> 3070 <p id="rfc.section.B.2.p.3">The original HTTP/1.0 form of persistent connections (the Connection: Keep-Alive and Keep-Alive header field) is documented 3071 in <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.9"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>. 3072 </p> 3073 <h2 id="rfc.section.B.3"><a href="#rfc.section.B.3">B.3</a> <a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h2> 3074 <p id="rfc.section.B.3.p.1">Empty list elements in list productions have been deprecated. (<a href="#notation.abnf" title="ABNF Extension: #rule">Section 1.2.1</a>) 3075 </p> 3076 <p id="rfc.section.B.3.p.2">Rules about implicit linear whitespace between certain grammar productions have been removed; now it's only allowed when specifically 3055 <h2 id="rfc.section.B.2"><a href="#rfc.section.B.2">B.2</a> <a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h2> 3056 <p id="rfc.section.B.2.p.1">Empty list elements in list productions have been deprecated. (<a href="#notation.abnf" title="ABNF Extension: #rule">Section 1.2.1</a>) 3057 </p> 3058 <p id="rfc.section.B.2.p.2">Rules about implicit linear whitespace between certain grammar productions have been removed; now it's only allowed when specifically 3077 3059 pointed out in the ABNF. The NUL octet is no longer allowed in comment and quoted-string text. The quoted-pair rule no longer 3078 3060 allows escaping control characters other than HTAB. Non-ASCII content in header fields and reason phrase has been obsoleted 3079 3061 and made opaque (the TEXT rule was removed) (<a href="#basic.rules" title="Basic Rules">Section 1.2.2</a>) 3080 3062 </p> 3081 <p id="rfc.section.B. 3.p.3">Clarify that HTTP-Version is case sensitive. (<a href="#http.version" title="Protocol Versioning">Section 2.5</a>)3082 </p> 3083 <p id="rfc.section.B. 3.p.4">Require that invalid whitespace around field-names be rejected. (<a href="#header.fields" title="Header Fields">Section 3.2</a>)3084 </p> 3085 <p id="rfc.section.B. 3.p.5">Require recipients to handle bogus Content-Length header fields as errors. (<a href="#message.body" title="Message Body">Section 3.3</a>)3086 </p> 3087 <p id="rfc.section.B. 3.p.6">Remove reference to non-existent identity transfer-coding value tokens. (Sections <a href="#message.body" title="Message Body">3.3</a> and <a href="#transfer.codings" title="Transfer Codings">6.2</a>)3088 </p> 3089 <p id="rfc.section.B. 3.p.7">Update use of abs_path production from RFC 1808 to the path-absolute + query components of RFC 3986. State that the asterisk3063 <p id="rfc.section.B.2.p.3">Clarify that HTTP-Version is case sensitive. (<a href="#http.version" title="Protocol Versioning">Section 2.5</a>) 3064 </p> 3065 <p id="rfc.section.B.2.p.4">Require that invalid whitespace around field-names be rejected. (<a href="#header.fields" title="Header Fields">Section 3.2</a>) 3066 </p> 3067 <p id="rfc.section.B.2.p.5">Require recipients to handle bogus Content-Length header fields as errors. (<a href="#message.body" title="Message Body">Section 3.3</a>) 3068 </p> 3069 <p id="rfc.section.B.2.p.6">Remove reference to non-existent identity transfer-coding value tokens. (Sections <a href="#message.body" title="Message Body">3.3</a> and <a href="#transfer.codings" title="Transfer Codings">6.2</a>) 3070 </p> 3071 <p id="rfc.section.B.2.p.7">Update use of abs_path production from RFC 1808 to the path-absolute + query components of RFC 3986. State that the asterisk 3090 3072 form is allowed for the OPTIONS request method only. (<a href="#request-target" title="request-target">Section 4.1.2</a>) 3091 3073 </p> 3092 <p id="rfc.section.B. 3.p.8">Clarification that the chunk length does not include the count of the octets in the chunk header and trailer. Furthermore3074 <p id="rfc.section.B.2.p.8">Clarification that the chunk length does not include the count of the octets in the chunk header and trailer. Furthermore 3093 3075 disallowed line folding in chunk extensions. (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section 6.2.1</a>) 3094 3076 </p> 3095 <p id="rfc.section.B. 3.p.9">Remove hard limit of two connections per server. (<a href="#persistent.practical" title="Practical Considerations">Section 7.1.4</a>)3096 </p> 3097 <p id="rfc.section.B. 3.p.10">Clarify exactly when close connection options must be sent. (<a href="#header.connection" id="rfc.xref.header.connection.11" title="Connection">Section 9.1</a>)3098 </p> 3099 <p id="rfc.section.B. 3.p.11">Define the semantics of the "Upgrade" header field in responses other than 101 (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.2"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#header.upgrade" id="rfc.xref.header.upgrade.3" title="Upgrade">Section 9.8</a>)3077 <p id="rfc.section.B.2.p.9">Remove hard limit of two connections per server. (<a href="#persistent.practical" title="Practical Considerations">Section 7.1.4</a>) 3078 </p> 3079 <p id="rfc.section.B.2.p.10">Clarify exactly when close connection options must be sent. (<a href="#header.connection" id="rfc.xref.header.connection.11" title="Connection">Section 9.1</a>) 3080 </p> 3081 <p id="rfc.section.B.2.p.11">Define the semantics of the "Upgrade" header field in responses other than 101 (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.2"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#header.upgrade" id="rfc.xref.header.upgrade.3" title="Upgrade">Section 9.8</a>) 3100 3082 </p> 3101 3083 <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> … … 3636 3618 <li>compress (Coding Format) <a href="#rfc.iref.c.8">6.2.2.1</a></li> 3637 3619 <li>connection <a href="#rfc.iref.c.2"><b>2.1</b></a></li> 3638 <li>Connection header field <a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.5</a>, <a href="#rfc.xref.header.connection.3">3.4</a>, <a href="#rfc.xref.header.connection.4">7.1.2</a>, <a href="#rfc.xref.header.connection.5">7.1.3</a>, <a href="#rfc.xref.header.connection.6">7.1.3.1</a>, <a href="#rfc.iref.c.12"><b>9.1</b></a>, <a href="#rfc.xref.header.connection.7">9.5</a>, <a href="#rfc.xref.header.connection.8">9.8</a>, <a href="#rfc.xref.header.connection.9">10.1</a>, <a href="#rfc.xref.header.connection.10">B. 2</a>, <a href="#rfc.xref.header.connection.11">B.3</a></li>3620 <li>Connection header field <a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.5</a>, <a href="#rfc.xref.header.connection.3">3.4</a>, <a href="#rfc.xref.header.connection.4">7.1.2</a>, <a href="#rfc.xref.header.connection.5">7.1.3</a>, <a href="#rfc.xref.header.connection.6">7.1.3.1</a>, <a href="#rfc.iref.c.12"><b>9.1</b></a>, <a href="#rfc.xref.header.connection.7">9.5</a>, <a href="#rfc.xref.header.connection.8">9.8</a>, <a href="#rfc.xref.header.connection.9">10.1</a>, <a href="#rfc.xref.header.connection.10">B.1.2</a>, <a href="#rfc.xref.header.connection.11">B.2</a></li> 3639 3621 <li>Content-Length header field <a href="#rfc.xref.header.content-length.1">3.3</a>, <a href="#rfc.iref.c.13"><b>9.2</b></a>, <a href="#rfc.xref.header.content-length.2">10.1</a></li> 3640 3622 </ul> … … 3779 3761 <li>Header Fields 3780 3762 <ul> 3781 <li>Connection <a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.5</a>, <a href="#rfc.xref.header.connection.3">3.4</a>, <a href="#rfc.xref.header.connection.4">7.1.2</a>, <a href="#rfc.xref.header.connection.5">7.1.3</a>, <a href="#rfc.xref.header.connection.6">7.1.3.1</a>, <a href="#rfc.iref.h.6"><b>9.1</b></a>, <a href="#rfc.xref.header.connection.7">9.5</a>, <a href="#rfc.xref.header.connection.8">9.8</a>, <a href="#rfc.xref.header.connection.9">10.1</a>, <a href="#rfc.xref.header.connection.10">B. 2</a>, <a href="#rfc.xref.header.connection.11">B.3</a></li>3763 <li>Connection <a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.5</a>, <a href="#rfc.xref.header.connection.3">3.4</a>, <a href="#rfc.xref.header.connection.4">7.1.2</a>, <a href="#rfc.xref.header.connection.5">7.1.3</a>, <a href="#rfc.xref.header.connection.6">7.1.3.1</a>, <a href="#rfc.iref.h.6"><b>9.1</b></a>, <a href="#rfc.xref.header.connection.7">9.5</a>, <a href="#rfc.xref.header.connection.8">9.8</a>, <a href="#rfc.xref.header.connection.9">10.1</a>, <a href="#rfc.xref.header.connection.10">B.1.2</a>, <a href="#rfc.xref.header.connection.11">B.2</a></li> 3782 3764 <li>Content-Length <a href="#rfc.xref.header.content-length.1">3.3</a>, <a href="#rfc.iref.h.7"><b>9.2</b></a>, <a href="#rfc.xref.header.content-length.2">10.1</a></li> 3783 3765 <li>Date <a href="#rfc.xref.header.date.1">3.4</a>, <a href="#rfc.iref.h.8"><b>9.3</b></a>, <a href="#rfc.xref.header.date.2">10.1</a></li> … … 3786 3768 <li>Trailer <a href="#rfc.xref.header.trailer.1">3.4</a>, <a href="#rfc.xref.header.trailer.2">6.2.1</a>, <a href="#rfc.iref.h.12"><b>9.6</b></a>, <a href="#rfc.xref.header.trailer.3">10.1</a></li> 3787 3769 <li>Transfer-Encoding <a href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a href="#rfc.xref.header.transfer-encoding.2">3.4</a>, <a href="#rfc.xref.header.transfer-encoding.3">6.2</a>, <a href="#rfc.iref.h.13"><b>9.7</b></a>, <a href="#rfc.xref.header.transfer-encoding.4">10.1</a></li> 3788 <li>Upgrade <a href="#rfc.xref.header.upgrade.1">3.4</a>, <a href="#rfc.iref.h.14"><b>9.8</b></a>, <a href="#rfc.xref.header.upgrade.2">10.1</a>, <a href="#rfc.xref.header.upgrade.3">B. 3</a></li>3770 <li>Upgrade <a href="#rfc.xref.header.upgrade.1">3.4</a>, <a href="#rfc.iref.h.14"><b>9.8</b></a>, <a href="#rfc.xref.header.upgrade.2">10.1</a>, <a href="#rfc.xref.header.upgrade.3">B.2</a></li> 3789 3771 <li>Via <a href="#rfc.xref.header.via.1">2.3</a>, <a href="#rfc.xref.header.via.2">3.4</a>, <a href="#rfc.iref.h.15"><b>9.9</b></a>, <a href="#rfc.xref.header.via.3">10.1</a></li> 3790 3772 </ul> … … 3879 3861 </li> 3880 3862 <li><em>RFC2047</em> <a href="#rfc.xref.RFC2047.1">3.2</a>, <a href="#RFC2047"><b>13.2</b></a></li> 3881 <li><em>RFC2068</em> <a href="#rfc.xref.RFC2068.1">2.5</a>, <a href="#rfc.xref.RFC2068.2">7.1.3</a>, <a href="#rfc.xref.RFC2068.3">7.2.3</a>, <a href="#rfc.xref.RFC2068.4">12</a>, <a href="#rfc.xref.RFC2068.5">13.1</a>, <a href="#rfc.xref.RFC2068.6">13.1</a>, <a href="#rfc.xref.RFC2068.7">13.1</a>, <a href="#RFC2068"><b>13.2</b></a>, <a href="#rfc.xref.RFC2068.8">B </a>, <a href="#rfc.xref.RFC2068.9">B.2</a><ul>3882 <li><em>Section 19.7.1</em> <a href="#rfc.xref.RFC2068.2">7.1.3</a>, <a href="#rfc.xref.RFC2068.8">B </a>, <a href="#rfc.xref.RFC2068.9">B.2</a></li>3863 <li><em>RFC2068</em> <a href="#rfc.xref.RFC2068.1">2.5</a>, <a href="#rfc.xref.RFC2068.2">7.1.3</a>, <a href="#rfc.xref.RFC2068.3">7.2.3</a>, <a href="#rfc.xref.RFC2068.4">12</a>, <a href="#rfc.xref.RFC2068.5">13.1</a>, <a href="#rfc.xref.RFC2068.6">13.1</a>, <a href="#rfc.xref.RFC2068.7">13.1</a>, <a href="#RFC2068"><b>13.2</b></a>, <a href="#rfc.xref.RFC2068.8">B.1.2</a><ul> 3864 <li><em>Section 19.7.1</em> <a href="#rfc.xref.RFC2068.2">7.1.3</a>, <a href="#rfc.xref.RFC2068.8">B.1.2</a></li> 3883 3865 </ul> 3884 3866 </li> … … 3886 3868 <li><em>RFC2145</em> <a href="#rfc.xref.RFC2145.1">1</a>, <a href="#RFC2145"><b>13.2</b></a></li> 3887 3869 <li><em>RFC2616</em> <a href="#rfc.xref.RFC2616.1">1</a>, <a href="#rfc.xref.RFC2616.2">2.5</a>, <a href="#rfc.xref.RFC2616.3">12</a>, <a href="#RFC2616"><b>13.2</b></a>, <a href="#rfc.xref.RFC2616.4">D.1</a></li> 3888 <li><em>RFC2817</em> <a href="#rfc.xref.RFC2817.1">10.5</a>, <a href="#RFC2817"><b>13.2</b></a>, <a href="#rfc.xref.RFC2817.2">B. 3</a><ul>3870 <li><em>RFC2817</em> <a href="#rfc.xref.RFC2817.1">10.5</a>, <a href="#RFC2817"><b>13.2</b></a>, <a href="#rfc.xref.RFC2817.2">B.2</a><ul> 3889 3871 <li><em>Section 7.2</em> <a href="#rfc.xref.RFC2817.1">10.5</a></li> 3890 3872 </ul> … … 3945 3927 </li> 3946 3928 <li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul> 3947 <li>Upgrade header field <a href="#rfc.xref.header.upgrade.1">3.4</a>, <a href="#rfc.iref.u.5"><b>9.8</b></a>, <a href="#rfc.xref.header.upgrade.2">10.1</a>, <a href="#rfc.xref.header.upgrade.3">B. 3</a></li>3929 <li>Upgrade header field <a href="#rfc.xref.header.upgrade.1">3.4</a>, <a href="#rfc.iref.u.5"><b>9.8</b></a>, <a href="#rfc.xref.header.upgrade.2">10.1</a>, <a href="#rfc.xref.header.upgrade.3">B.2</a></li> 3948 3930 <li>upstream <a href="#rfc.iref.u.2"><b>2.3</b></a></li> 3949 3931 <li>URI scheme -
draft-ietf-httpbis/latest/p1-messaging.xml
r1176 r1178 1186 1186 </t> 1187 1187 <t> 1188 Some old HTTP/1.0 client implementations generatean extra CRLF1188 Some old HTTP/1.0 client implementations send an extra CRLF 1189 1189 after a POST request as a lame workaround for some early server 1190 1190 applications that failed to read message-body content that was … … 4895 4895 </section> 4896 4896 4897 <section title=" Compatibility with Previous Versions" anchor="compatibility">4897 <section title="HTTP Version History" anchor="compatibility"> 4898 4898 <t> 4899 4899 HTTP has been in use by the World-Wide Web global information initiative … … 4921 4921 It is beyond the scope of a protocol specification to mandate 4922 4922 compliance with previous versions. HTTP/1.1 was deliberately 4923 designed, however, to make supporting previous versions easy. It is 4924 worth noting that, at the time of composing this specification, we would 4925 expect general-purpose HTTP/1.1 servers to: 4926 <list style="symbols"> 4927 <t>understand any valid request in the format of HTTP/1.0 and 4928 1.1;</t> 4929 4930 <t>respond appropriately with a message in the same major version 4931 used by the client.</t> 4932 </list> 4933 </t> 4934 <t> 4935 And we would expect HTTP/1.1 clients to: 4936 <list style="symbols"> 4937 <t>understand any valid response in the format of HTTP/1.0 or 4938 1.1.</t> 4939 </list> 4940 </t> 4941 <t> 4942 For most implementations of HTTP/1.0, each connection is established 4943 by the client prior to the request and closed by the server after 4944 sending the response. Some implementations implement the Keep-Alive 4945 version of persistent connections described in <xref x:sec="19.7.1" x:fmt="of" target="RFC2068"/>. 4923 designed, however, to make supporting previous versions easy. 4924 We would expect a general-purpose HTTP/1.1 server to understand 4925 any valid request in the format of HTTP/1.0 and respond appropriately 4926 with an HTTP/1.1 message that only uses features understood (or 4927 safely ignored) by HTTP/1.0 clients. Likewise, would expect 4928 an HTTP/1.1 client to understand any valid HTTP/1.0 response. 4929 </t> 4930 <t> 4931 Since HTTP/0.9 did not support header fields in a request, 4932 there is no mechanism for it to support name-based virtual 4933 hosts (selection of resource by inspection of the Host header 4934 field). Any server that implements name-based virtual hosts 4935 ought to disable support for HTTP/0.9. Most requests that 4936 appear to be HTTP/0.9 are, in fact, badly constructed HTTP/1.x 4937 requests wherein a buggy client failed to properly encode 4938 linear whitespace found in a URI reference and placed in 4939 the request-target. 4946 4940 </t> 4947 4941 … … 4952 4946 </t> 4953 4947 4954 <section title=" Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses" anchor="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses">4948 <section title="Multi-homed Web Servers" anchor="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses"> 4955 4949 <t> 4956 4950 The requirements that clients and servers support the Host header 4957 4951 field (<xref target="header.host"/>), report an error if it is 4958 4952 missing from an HTTP/1.1 request, and accept absolute URIs (<xref target="request-target"/>) 4959 are among the most important changes defined by this 4960 specification. 4953 are among the most important changes defined by HTTP/1.1. 4961 4954 </t> 4962 4955 <t> … … 4964 4957 addresses and servers; there was no other established mechanism for 4965 4958 distinguishing the intended server of a request than the IP address 4966 to which that request was directed. The changes outlined above will 4967 allow the Internet, once older HTTP clients are no longer common, to 4968 support multiple Web sites from a single IP address, greatly 4969 simplifying large operational Web servers, where allocation of many 4970 IP addresses to a single host has created serious problems. The 4971 Internet will also be able to recover the IP addresses that have been 4972 allocated for the sole purpose of allowing special-purpose domain 4973 names to be used. Given the rate of growth of 4974 the Web, and the number of servers already deployed, it is extremely 4975 important that all implementations of HTTP (including updates to 4976 existing HTTP/1.0 applications) correctly implement these 4977 requirements: 4978 <list style="symbols"> 4979 <t>Both clients and servers &MUST; support the Host header field.</t> 4980 4981 <t>A client that sends an HTTP/1.1 request &MUST; send a Host header field.</t> 4982 4983 <t>Servers &MUST; report a 400 (Bad Request) error if an HTTP/1.1 4984 request does not include a Host header field.</t> 4985 4986 <t>Servers &MUST; accept absolute URIs.</t> 4987 </list> 4988 </t> 4989 </section> 4990 </section> 4991 4992 <section title="Compatibility with HTTP/1.0 Persistent Connections" anchor="compatibility.with.http.1.0.persistent.connections"> 4959 to which that request was directed. The Host header field was 4960 introduced during the development of HTTP/1.1 and, though it was 4961 quickly implemented by most HTTP/1.0 browsers, additional requirements 4962 were placed on all HTTP/1.1 requests in order to ensure complete 4963 adoption. At the time of this writing, most HTTP-based services 4964 are dependent upon the Host header field for targeting requests. 4965 </t> 4966 </section> 4967 4968 <section title="Keep-Alive Connections" anchor="compatibility.with.http.1.0.persistent.connections"> 4969 <t> 4970 For most implementations of HTTP/1.0, each connection is established 4971 by the client prior to the request and closed by the server after 4972 sending the response. However, some implementations implement the 4973 Keep-Alive version of persistent connections described in 4974 <xref x:sec="19.7.1" x:fmt="of" target="RFC2068"/>. 4975 </t> 4993 4976 <t> 4994 4977 Some clients and servers might wish to be compatible with some … … 5015 4998 declaring non-persistence. See <xref target="header.connection"/>. 5016 4999 </t> 5017 <t> 5018 The original HTTP/1.0 form of persistent connections (the Connection: 5019 Keep-Alive and Keep-Alive header field) is documented in <xref x:sec="19.7.1" x:fmt="of" target="RFC2068"/>. 5020 </t> 5000 </section> 5021 5001 </section> 5022 5002
Note: See TracChangeset
for help on using the changeset viewer.