Re: #273: HTTP-Version should be redefined as fixed length pair of DIGIT . DIGIT

On 2011-06-25 10:01, Willy Tarreau wrote:
> Hi Julian,
>
> On Sat, Jun 25, 2011 at 09:40:43AM +0200, Julian Reschke wrote:
>> On 2011-06-25 00:14, Willy Tarreau wrote:
>>> Hi Julian,
>>>
>>> On Fri, Jun 24, 2011 at 10:16:26PM +0200, Julian Reschke wrote:
>>>>     The HTTP version number consists of two non-negative decimal digits
>>>
>>> Since "integer" was changed to "digits" here, maybe we can remove the
>>> "non-negative" precision ?
>>> ...
>>
>> Oops. I know I had this right, but somehow it didn't end up in the
>> patch. See updated patch at
>> <http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/273/273.diff>.
>
> Another point on wording, should we say "The first number" or "The first digit" ?
>
> The risk of ambiguity is very low, but we're saying that the "HTTP version
> number" is composed of two digits, then when we say "the first number", it
> might be possible to read it as the HTTP version number composed from the
> two digits. I think that talking only about digits removes any doubt :
>
>      The HTTP version number consists of two decimal digits separated by a "."
>      (period or decimal point).  The first digit ("major version") indicates the
>      HTTP messaging syntax, whereas the second digit ("minor version") indicates
>      the highest minor version to which the sender is at least conditionally
>      compliant and able to understand for future communication.

Indeed; I have updated the patch accordingly.

2.5 now would read:

2.5.  Protocol Versioning

    HTTP uses a "<major>.<minor>" numbering scheme to indicate versions
    of the protocol.  This specification defines version "1.1".  The
    protocol version as a whole indicates the sender's compliance with
    the set of requirements laid out in that version's corresponding
    specification of HTTP.

    The version of an HTTP message is indicated by an HTTP-Version field
    in the first line of the message.  HTTP-Version is case-sensitive.

      HTTP-Version   = HTTP-Prot-Name "/" DIGIT "." DIGIT
      HTTP-Prot-Name = %x48.54.54.50 ; "HTTP", case-sensitive

    The HTTP version number consists of two decimal digits separated by a
    "." (period or decimal point).  The first digit ("major version")
    indicates the HTTP messaging syntax, whereas the second digit ("minor
    version") indicates the highest minor version to which the sender is
    at least conditionally compliant and able to understand for future
    communication.  The minor version advertises the sender's
    communication capabilities even when the sender is only using a
    backwards-compatible subset of the protocol, thereby letting the
    recipient know that more advanced features can be used in response
    (by servers) or in future requests (by clients).

    When an HTTP/1.1 message is sent to an HTTP/1.0 recipient [RFC1945]
    or a recipient whose version is unknown, the HTTP/1.1 message is
    constructed such that it can be interpreted as a valid HTTP/1.0
    message if all of the newer features are ignored.  This specification
    places recipient-version requirements on some new features so that a
    compliant sender will only use compatible features until it has
    determined, through configuration or the receipt of a message, that
    the recipient supports HTTP/1.1.

    The interpretation of an HTTP header field does not change between
    minor versions of the same major version, though the default behavior
    of a recipient in the absence of such a field can change.  Unless
    specified otherwise, header fields defined in HTTP/1.1 are defined
    for all versions of HTTP/1.x.  In particular, the Host and Connection
    header fields ought to be implemented by all HTTP/1.x implementations
    whether or not they advertise compliance with HTTP/1.1.

    New header fields can be defined such that, when they are understood
    by a recipient, they might override or enhance the interpretation of
    previously defined header fields.  When an implementation receives an
    unrecognized header field, the recipient MUST ignore that header
    field for local processing regardless of the message's HTTP version.
    An unrecognized header field received by a proxy MUST be forwarded
    downstream unless the header field's field-name is listed in the
    message's Connection header-field (see Section 9.1).  These
    requirements allow HTTP's functionality to be enhanced without
    requiring prior update of all compliant intermediaries.

    Intermediaries that process HTTP messages (i.e., all intermediaries
    other than those acting as a tunnel) MUST send their own HTTP-Version
    in forwarded messages.  In other words, they MUST NOT blindly forward
    the first line of an HTTP message without ensuring that the protocol
    version matches what the intermediary understands, and is at least
    conditionally compliant to, for both the receiving and sending of
    messages.  Forwarding an HTTP message without rewriting the HTTP-
    Version might result in communication errors when downstream
    recipients use the message sender's version to determine what
    features are safe to use for later communication with that sender.

    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 attempted at least one normal request and
    determined from the response status or header fields (e.g., Server)
    that the server improperly handles higher request versions.

    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 it cannot send a response using
    the major version used in the client's request.

    An HTTP server MAY send an HTTP/1.0 response to an HTTP/1.0 request
    if it is known or suspected that the client incorrectly implements
    the HTTP specification and is incapable of correctly processing later
    version responses, such as when a client fails to parse the version
    number correctly or when an intermediary is known to blindly forward
    the HTTP-Version even when it doesn't comply with the given minor
    version of the protocol.  Such protocol downgrades SHOULD NOT be
    performed unless triggered by specific client attributes, such as
    when one or more of the request header fields (e.g., User-Agent)
    uniquely match the values sent by a client known to be in error.

    The intention of HTTP's versioning design is that the major number
    will only be incremented if an incompatible message syntax is
    introduced, and that the minor number will only be incremented when
    changes made to the protocol have the effect of adding to the message
    semantics or implying additional capabilities of the sender.
    However, the minor version was not incremented for the changes
    introduced between [RFC2068] and [RFC2616], and this revision is
    specifically avoiding any such changes to the protocol.

Best regards, Julian

Received on Saturday, 25 June 2011 08:40:07 UTC