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.

File:
1 edited

Legend:

Unmodified
Added
Removed
  • 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.