Changeset 1178 for draft-ietf-httpbis/latest/p1-messaging.xml

Timestamp:

14/03/11 05:07:18 (10 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:

• draft-ietf-httpbis/latest/p1-messaging.xml (modified) (6 diffs)

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

@@ -1186 +1186 @@
 </t>
 <t>
-   Some old HTTP/1.0 client implementations generate an extra CRLF
+   Some old HTTP/1.0 client implementations send an extra CRLF
    after a POST request as a lame workaround for some early server
    applications that failed to read message-body content that was
@@ -4895 +4895 @@
 </section>
 
-<section title="Compatibility with Previous Versions" anchor="compatibility">
+<section title="HTTP Version History" anchor="compatibility">
 <t>
    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
    compliance with previous versions. HTTP/1.1 was deliberately
-   designed, however, to make supporting previous versions easy. It is
-   worth noting that, at the time of composing this specification, we would
-   expect general-purpose HTTP/1.1 servers to:
-  <list style="symbols">
-     <t>understand any valid request in the format of HTTP/1.0 and
-        1.1;</t>
-
-     <t>respond appropriately with a message in the same major version
-        used by the client.</t>
-  </list>
-</t>
-<t>
-   And we would expect HTTP/1.1 clients to:
-  <list style="symbols">
-     <t>understand any valid response in the format of HTTP/1.0 or
-        1.1.</t>
-  </list>
-</t>
-<t>
-   For most implementations of HTTP/1.0, each connection is established
-   by the client prior to the request and closed by the server after
-   sending the response. Some implementations implement the Keep-Alive
-   version of persistent connections described in <xref x:sec="19.7.1" x:fmt="of" target="RFC2068"/>.
+   designed, however, to make supporting previous versions easy.
+   We would expect a general-purpose HTTP/1.1 server to understand
+   any valid request in the format of HTTP/1.0 and respond appropriately
+   with an HTTP/1.1 message that only uses features understood (or
+   safely ignored) by HTTP/1.0 clients.  Likewise, would expect
+   an HTTP/1.1 client to understand any valid HTTP/1.0 response.
+</t>
+<t>
+   Since HTTP/0.9 did not support header fields in a request,
+   there is no mechanism for it to support name-based virtual
+   hosts (selection of resource by inspection of the Host header
+   field).  Any server that implements name-based virtual hosts
+   ought 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 wherein a buggy client failed to properly encode
+   linear whitespace found in a URI reference and placed in
+   the request-target.
 </t>
 
@@ -4952 +4946 @@
 </t>
 
-<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">
+<section title="Multi-homed Web Servers" anchor="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses">
 <t>
    The requirements that clients and servers support the Host header
    field (<xref target="header.host"/>), report an error if it is
    missing from an HTTP/1.1 request, and accept absolute URIs (<xref target="request-target"/>)
-   are among the most important changes defined by this
-   specification.
+   are among the most important changes defined by HTTP/1.1.
 </t>
 <t>
@@ -4964 +4957 @@
    addresses and servers; there was no other established mechanism for
    distinguishing the intended server of a request than the IP address
-   to which that request was directed. The changes outlined above will
-   allow the Internet, once older HTTP clients are no longer common, to
-   support multiple Web sites from a single IP address, greatly
-   simplifying large operational Web servers, where allocation of many
-   IP addresses to a single host has created serious problems. The
-   Internet will also be able to recover the IP addresses that have been
-   allocated for the sole purpose of allowing special-purpose domain
-   names to be used. Given the rate of growth of
-   the Web, and the number of servers already deployed, it is extremely
-   important that all implementations of HTTP (including updates to
-   existing HTTP/1.0 applications) correctly implement these
-   requirements:
-  <list style="symbols">
-     <t>Both clients and servers &MUST; support the Host header field.</t>
-
-     <t>A client that sends an HTTP/1.1 request &MUST; send a Host header field.</t>
-
-     <t>Servers &MUST; report a 400 (Bad Request) error if an HTTP/1.1
-        request does not include a Host header field.</t>
-
-     <t>Servers &MUST; accept absolute URIs.</t>
-  </list>
-</t>
-</section>
-</section>
-
-<section title="Compatibility with HTTP/1.0 Persistent Connections" anchor="compatibility.with.http.1.0.persistent.connections">
+   to which that request was directed. The Host header field was
+   introduced during the development of HTTP/1.1 and, though it was
+   quickly implemented by most HTTP/1.0 browsers, additional requirements
+   were placed on all HTTP/1.1 requests in order to ensure complete
+   adoption.  At the time of this writing, most HTTP-based services
+   are dependent upon the Host header field for targeting requests.
+</t>
+</section>
+
+<section title="Keep-Alive Connections" anchor="compatibility.with.http.1.0.persistent.connections">
+<t>
+   For most implementations of HTTP/1.0, each connection is established
+   by the client prior to the request and closed by the server after
+   sending the response. However, some implementations implement the
+   Keep-Alive version of persistent connections described in
+   <xref x:sec="19.7.1" x:fmt="of" target="RFC2068"/>.
+</t>
 <t>
    Some clients and servers might wish to be compatible with some
@@ -5015 +4998 @@
    declaring non-persistence. See <xref target="header.connection"/>.
 </t>
-<t>
-   The original HTTP/1.0 form of persistent connections (the Connection:
-   Keep-Alive and Keep-Alive header field) is documented in <xref x:sec="19.7.1" x:fmt="of" target="RFC2068"/>.
-</t>
+</section>
 </section>