2.1 Proxy behavior

   A proxy MUST forward an unknown header, unless it is protected by a
   Connection header.  A proxy implementing an HTTP version >= 1.1 MUST
   NOT forward unknown headers that are protected by a Connection
   header, as described in section 14.10 of the HTTP/1.1 specification
   [2].

   We remind the reader that that HTTP version numbers are hop-by-hop
   components of HTTP messages, and are not end-to-end.  That is, an
   HTTP proxy never "forwards" an HTTP version number in either a
   request or response.

2.2 Compatibility between minor versions of the same major version

   An implementation of HTTP/x.b sending a message to a recipient whose
   version is known to be HTTP/x.a, a < b, MAY send a header that is not
   defined in the specification for HTTP/x.a.  For example, an HTTP/1.1
   server may send a "Cache-control" header to an HTTP/1.0 client; this
   may be useful if the immediate recipient is an HTTP/1.0 proxy, but
   the ultimate recipient is an HTTP/1.1 client.





 
RFC 2145                  HTTP Version Numbers                  May 1997


   An implementation of HTTP/x.b sending a message to a recipient whose
   version is known to be HTTP/x.a, a < b, MUST NOT depend on the
   recipient understanding a header not defined in the specification for
   HTTP/x.a.  For example, HTTP/1.0 clients cannot be expected to
   understand chunked encodings, and so an HTTP/1.1 server must never
   send "Transfer-Encoding: chunked" in response to an HTTP/1.0 request.

2.3 Which version number to send in a message

   The most strenuous debate over the use of HTTP version numbers has
   centered on the problem of implementations that do not follow the
   robustness principle, and which fail to produce useful results when
   they receive a message with an HTTP minor version higher than the
   minor version they implement.  We consider these implementations
   buggy, but we recognize that the robustness principle also implies
   that message senders should make concessions to buggy implementations
   when this is truly necessary for interoperation.

   An HTTP client SHOULD send a request version equal to the highest
   version for which the client is at least conditionally compliant, and
   whose major version is no higher than the highest version supported
   by the server, if this is known.  An HTTP client MUST NOT send a
   version for which it is not at least conditionally compliant.

   An HTTP client MAY send a lower request version, if it is known that
   the server incorrectly implements the HTTP specification, but only
   after the client has determined that the server is actually buggy.

   An HTTP server SHOULD send a response version equal to the highest
   version for which the server is at least conditionally compliant, and
   whose major version is less than or equal to the one received in the
   request.  An HTTP server MUST NOT send a version for which it is not
   at least conditionally compliant.  A server MAY send a 505 (HTTP
   Version Not Supported) response if cannot send a response using the
   major version used in the client's request.

   An HTTP server MAY send a lower response version, if it is known or
   suspected that the client incorrectly implements the HTTP
   specification, but this should not be the default, and this SHOULD
   NOT be done if the request version is HTTP/1.1 or greater.












 
RFC 2145                  HTTP Version Numbers                  May 1997


3 Security Considerations

   None, except to the extent that security mechanisms introduced in one
   version of HTTP might depend on the proper interpretation of HTTP
   version numbers in older implementations.

4 References

   1.  Berners-Lee, T.,  R. Fielding, and H. Frystyk.  Hypertext
   Transfer Protocol -- HTTP/1.0.  RFC 1945, HTTP Working Group, May,
   1996.

   2.  Fielding, Roy T., Jim Gettys, Jeffrey C. Mogul, Henrik Frystyk
   Nielsen, and Tim Berners-Lee.  Hypertext Transfer Protocol --