been used as a combination of the existing Location, Content-
   Location, and Vary header fields as well as the future Alternates




 
RFC 2068                        HTTP/1.1                    January 1997


   field (above). Its primary purpose has been to include a list of
   additional URIs for the resource, including names and mirror
   locations. However, it has become clear that the combination of many
   different functions within this single field has been a barrier to
   consistently and correctly implementing any of those functions.
   Furthermore, we believe that the identification of names and mirror
   locations would be better performed via the Link header field. The
   URI header field is therefore deprecated in favor of those other
   fields.

          URI-header    = "URI" ":" 1#( "<" URI ">" )

19.7 Compatibility with Previous Versions

   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 commercial HTTP/1.1 servers to:

  o  recognize the format of the Request-Line for HTTP/0.9, 1.0, and 1.1
     requests;

  o  understand any valid request in the format of HTTP/0.9, 1.0, or
     1.1;

  o  respond appropriately with a message in the same major version used
     by the client.

   And we would expect HTTP/1.1 clients to:

  o  recognize the format of the Status-Line for HTTP/1.0 and 1.1
     responses;

  o  understand any valid response in the format of HTTP/0.9, 1.0, or
     1.1.

   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. A few implementations implement the Keep-Alive
   version of persistent connections described in section 19.7.1.1.











 
RFC 2068                        HTTP/1.1                    January 1997


19.7.1 Compatibility with HTTP/1.0 Persistent Connections

   Some clients and servers may wish to be compatible with some previous
   implementations of persistent connections in HTTP/1.0 clients and
   servers. Persistent connections in HTTP/1.0 must be explicitly
   negotiated as they are not the default behavior. HTTP/1.0
   experimental implementations of persistent connections are faulty,
   and the new facilities in HTTP/1.1 are designed to rectify these
   problems. The problem was that some existing 1.0 clients may be
   sending Keep-Alive to a proxy server that doesn't understand
   Connection, which would then erroneously forward it to the next
   inbound server, which would establish the Keep-Alive connection and
   result in a hung HTTP/1.0 proxy waiting for the close on the
   response. The result is that HTTP/1.0 clients must be prevented from
   using Keep-Alive when talking to proxies.

   However, talking to proxies is the most important use of persistent
   connections, so that prohibition is clearly unacceptable. Therefore,
   we need some other mechanism for indicating a persistent connection
   is desired, which is safe to use even when talking to an old proxy
   that ignores Connection. Persistent connections are the default for
   HTTP/1.1 messages; we introduce a new keyword (Connection: close) for
   declaring non-persistence.

   The following describes the original HTTP/1.0 form of persistent
   connections.

   When it connects to an origin server, an HTTP client MAY send the
   Keep-Alive connection-token in addition to the Persist connection-
   token:

          Connection: Keep-Alive

   An HTTP/1.0 server would then respond with the Keep-Alive connection