RFC 2145 (rfc2145) - Page 3 of 7

Use and Interpretation of HTTP Version Numbers

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

   RFC 791 [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.)





Mogul, et. al.               Informational