Ignore:
Timestamp:
Mar 13, 2011, 10:07:18 PM (9 years ago)
Author:
fielding@…
Message:

modernize the version history notes in the appendix and
remove redundant restated requirements that don't belong
in appendices.

Location:
draft-ietf-httpbis/latest
Files:
2 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p1-messaging.html

    r1177 r1178  
    395395      <link rel="Chapter" href="#rfc.section.13" title="13 References">
    396396      <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">
    398398      <link rel="Appendix" title="C Collected ABNF" href="#rfc.section.C">
    399399      <link rel="Appendix" title="D Change Log (to be removed by RFC Editor before publication)" href="#rfc.section.D">
    … …  
    685685         <li><a href="#rfc.authors">Authors' Addresses</a></li>
    686686         <li>A.&nbsp;&nbsp;&nbsp;<a href="#tolerant.applications">Tolerant Applications</a></li>
    687          <li>B.&nbsp;&nbsp;&nbsp;<a href="#compatibility">Compatibility with Previous Versions</a><ul>
     687         <li>B.&nbsp;&nbsp;&nbsp;<a href="#compatibility">HTTP Version History</a><ul>
    688688               <li>B.1&nbsp;&nbsp;&nbsp;<a href="#changes.from.1.0">Changes from HTTP/1.0</a><ul>
    689                      <li>B.1.1&nbsp;&nbsp;&nbsp;<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&nbsp;&nbsp;&nbsp;<a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses">Multi-homed Web Servers</a></li>
     690                     <li>B.1.2&nbsp;&nbsp;&nbsp;<a href="#compatibility.with.http.1.0.persistent.connections">Keep-Alive Connections</a></li>
    690691                  </ul>
    691692               </li>
    692                <li>B.2&nbsp;&nbsp;&nbsp;<a href="#compatibility.with.http.1.0.persistent.connections">Compatibility with HTTP/1.0 Persistent Connections</a></li>
    693                <li>B.3&nbsp;&nbsp;&nbsp;<a href="#changes.from.rfc.2616">Changes from RFC 2616</a></li>
     693               <li>B.2&nbsp;&nbsp;&nbsp;<a href="#changes.from.rfc.2616">Changes from RFC 2616</a></li>
    694694            </ul>
    695695         </li>
    … …  
    11951195         stream at the beginning of a message and receives a CRLF first, it <em class="bcp14">SHOULD</em> ignore the CRLF.
    11961196      </p>
    1197       <p id="rfc.section.3.1.p.2">Some old HTTP/1.0 client implementations generate an extra CRLF after a POST request as a lame workaround for some early server
     1197      <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
    11981198         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
    11991199         the client <em class="bcp14">MUST</em> include the terminating CRLF octets as part of the message-body length.
    … …  
    14831483         field.
    14841484      </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&nbsp;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&nbsp;B.1.1</a> for other requirements on Host support in HTTP/1.1.)
    14861486      </p>
    14871487      <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
    … …  
    18661866         for the connection.
    18671867      </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&nbsp;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&nbsp;B.1.2</a> for more information on backward compatibility with HTTP/1.0 clients.
    18691869      </p>
    18701870      <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&nbsp;3.3</a>.
    … …  
    22122212         message that contains more than one Host header field or a Host header field with an invalid field-value.
    22132213      </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.
    22152215      </p>
    22162216      <div id="rfc.iref.t.5"></div>
    … …  
    30013001         </li>
    30023002      </ul>
    3003       <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="compatibility" href="#compatibility">Compatibility with Previous Versions</a></h1>
     3003      <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="compatibility" href="#compatibility">HTTP Version History</a></h1>
    30043004      <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
    30053005         to as HTTP/0.9, was a simple protocol for hypertext data transfer across the Internet with only a single request method (GET)
    … …  
    30153015      </p>
    30163016      <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.
    30313025      </p>
    30323026      <h2 id="rfc.section.B.1"><a href="#rfc.section.B.1">B.1</a>&nbsp;<a id="changes.from.1.0" href="#changes.from.1.0">Changes from HTTP/1.0</a></h2>
    30333027      <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>&nbsp;<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&nbsp;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&nbsp;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>&nbsp;<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&nbsp;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&nbsp;4.1.2</a>) are among the most important changes defined by HTTP/1.1.
    30363030      </p>
    30373031      <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>&nbsp;<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>&nbsp;<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
    30583043         clients and servers. Persistent connections in HTTP/1.0 are explicitly negotiated as they are not the default behavior. HTTP/1.0
    30593044         experimental implementations of persistent connections are faulty, and the new facilities in HTTP/1.1 are designed to rectify
    … …  
    30633048         from using Keep-Alive when talking to proxies.
    30643049      </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.
    30663051         Therefore, we need some other mechanism for indicating a persistent connection is desired, which is safe to use even when
    30673052         talking to an old proxy that ignores Connection. Persistent connections are the default for HTTP/1.1 messages; we introduce
    30683053         a new keyword (Connection: close) for declaring non-persistence. See <a href="#header.connection" id="rfc.xref.header.connection.10" title="Connection">Section&nbsp;9.1</a>.
    30693054      </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>&nbsp;<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&nbsp;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>&nbsp;<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&nbsp;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
    30773059         pointed out in the ABNF. The NUL octet is no longer allowed in comment and quoted-string text. The quoted-pair rule no longer
    30783060         allows escaping control characters other than HTAB. Non-ASCII content in header fields and reason phrase has been obsoleted
    30793061         and made opaque (the TEXT rule was removed) (<a href="#basic.rules" title="Basic Rules">Section&nbsp;1.2.2</a>)
    30803062      </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&nbsp;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&nbsp;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&nbsp;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 asterisk
     3063      <p id="rfc.section.B.2.p.3">Clarify that HTTP-Version is case sensitive. (<a href="#http.version" title="Protocol Versioning">Section&nbsp;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&nbsp;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&nbsp;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
    30903072         form is allowed for the OPTIONS request method only. (<a href="#request-target" title="request-target">Section&nbsp;4.1.2</a>)
    30913073      </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. Furthermore
     3074      <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
    30933075         disallowed line folding in chunk extensions. (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;6.2.1</a>)
    30943076      </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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;9.8</a>)
    31003082      </p>
    31013083      <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
    … …  
    36363618                  <li>compress (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.8">6.2.2.1</a></li>
    36373619                  <li>connection&nbsp;&nbsp;<a href="#rfc.iref.c.2"><b>2.1</b></a></li>
    3638                   <li>Connection header field&nbsp;&nbsp;<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&nbsp;&nbsp;<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>
    36393621                  <li>Content-Length header field&nbsp;&nbsp;<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>
    36403622               </ul>
    … …  
    37793761                  <li>Header Fields&nbsp;&nbsp;
    37803762                     <ul>
    3781                         <li>Connection&nbsp;&nbsp;<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&nbsp;&nbsp;<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>
    37823764                        <li>Content-Length&nbsp;&nbsp;<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>
    37833765                        <li>Date&nbsp;&nbsp;<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>
    … …  
    37863768                        <li>Trailer&nbsp;&nbsp;<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>
    37873769                        <li>Transfer-Encoding&nbsp;&nbsp;<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&nbsp;&nbsp;<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&nbsp;&nbsp;<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>
    37893771                        <li>Via&nbsp;&nbsp;<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>
    37903772                     </ul>
    … …  
    38793861                  </li>
    38803862                  <li><em>RFC2047</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2047.1">3.2</a>, <a href="#RFC2047"><b>13.2</b></a></li>
    3881                   <li><em>RFC2068</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.RFC2068.2">7.1.3</a>, <a href="#rfc.xref.RFC2068.8">B.1.2</a></li>
    38833865                     </ul>
    38843866                  </li>
    … …  
    38863868                  <li><em>RFC2145</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2145.1">1</a>, <a href="#RFC2145"><b>13.2</b></a></li>
    38873869                  <li><em>RFC2616</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>
    38893871                        <li><em>Section 7.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2817.1">10.5</a></li>
    38903872                     </ul>
    … …  
    39453927            </li>
    39463928            <li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul>
    3947                   <li>Upgrade header field&nbsp;&nbsp;<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&nbsp;&nbsp;<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>
    39483930                  <li>upstream&nbsp;&nbsp;<a href="#rfc.iref.u.2"><b>2.3</b></a></li>
    39493931                  <li>URI scheme&nbsp;&nbsp;

  • draft-ietf-httpbis/latest/p1-messaging.xml

    r1176 r1178  
    11861186</t>
    11871187<t>
    1188    Some old HTTP/1.0 client implementations generate an extra CRLF
     1188   Some old HTTP/1.0 client implementations send an extra CRLF
    11891189   after a POST request as a lame workaround for some early server
    11901190   applications that failed to read message-body content that was
    … …  
    48954895</section>
    48964896
    4897 <section title="Compatibility with Previous Versions" anchor="compatibility">
     4897<section title="HTTP Version History" anchor="compatibility">
    48984898<t>
    48994899   HTTP has been in use by the World-Wide Web global information initiative
    … …  
    49214921   It is beyond the scope of a protocol specification to mandate
    49224922   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.
    49464940</t>
    49474941
    … …  
    49524946</t>
    49534947
    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">
    49554949<t>
    49564950   The requirements that clients and servers support the Host header
    49574951   field (<xref target="header.host"/>), report an error if it is
    49584952   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.
    49614954</t>
    49624955<t>
    … …  
    49644957   addresses and servers; there was no other established mechanism for
    49654958   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>
    49934976<t>
    49944977   Some clients and servers might wish to be compatible with some
    … …  
    50154998   declaring non-persistence. See <xref target="header.connection"/>.
    50164999</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>
    50215001</section>
    50225002
Note: See TracChangeset for help on using the changeset viewer.