HTTP/1.0.  This has led to debate and inconsistency regarding the use
   and interpretation of HTTP version numbers, and has led to
   interoperability problems in certain cases.











 
RFC 2145                  HTTP Version Numbers                  May 1997


   This document is an attempt to clarify the situation.  It is not a
   modification of the intended meaning of the existing HTTP/1.0 and
   HTTP/1.1 documents, but it does describe the intention of the authors
   of those documents.  In any case where either of those two documents
   is ambiguous regarding the use and interpretation of HTTP version
   numbers, this document should be considered the definitive as to the
   intentions of the designers of HTTP.

   The specification described in this document is not part of the
   specification of any individual version of HTTP, such as HTTP/1.0 or
   HTTP/1.1.  Rather, this document describes the use of HTTP version
   numbers in any version of HTTP (except for HTTP/0.9, which did not
   include version numbers).

   No vendor or other provider of an HTTP implementation should claim
   any compliance with any IETF HTTP specification unless the
   implementation conditionally complies with the rules in this
   document.

1.1 Robustness Principle

   RFC791 [4] defines the "robustness principle" in section 3.2:

          an implementation must be conservative in its sending
       behavior, and liberal in its receiving behavior.

   This principle applies to HTTP, as well.  It is the fundamental basis
   for interpreting any part of the HTTP specification that might still
   be ambiguous.  In particular, implementations of HTTP SHOULD NOT
   reject messages or generate errors unnecessarily.

2 HTTP version numbers

   We start by restating the language quoted above from section 3.1 of
   the HTTP/1.1 specification [2]:

         It is, and has always been, the explicit intent of the
      HTTP specification that the interpretation of an HTTP message
      header does not change between minor versions of the same major
      version.

         It is, and has always been, the explicit intent of the
      HTTP specification that an implementation receiving a message
      header that it does not understand MUST ignore that header.  (The
      word "ignore" has a special meaning for proxies; see section 2.1
      below.)






 
RFC 2145                  HTTP Version Numbers                  May 1997


   To make this as clear as possible:  The major version sent in a
   message MAY indicate the interpretation of other header fields.  The
   minor version sent in a message MUST NOT indicate the interpretation
   of other header fields.  This reflects the principle that the minor
   version labels the capability of the sender, not the interpretation
   of the message.

      Note: In a future version of HTTP, we may introduce a mechanism
      that explicitly requires a receiving implementation to reject a
      message if it does not understand certain headers.  For example,
      this might be implemented by means of a header that lists a set of
      other message headers that must be understood by the recipient.
      Any implementation claiming at least conditional compliance with
      this future version of HTTP would have to implement this
      mechanism.  However, no implementation claiming compliance with a
      lower HTTP version (in particular, HTTP/1.1) will have to
      implement this mechanism.

      This future change may be required to support the Protocol
      Extension Protocol (PEP) [3].

   One consequence of these rules is that an HTTP/1.1 message sent to an
   HTTP/1.0 recipient (or a recipient whose version is unknown) MUST be
   constructed so that it remains a valid HTTP/1.0 message when all
   headers not defined in the HTTP/1.0 specification [1] are removed.