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

On 2011-06-24 15:28, Willy Tarreau wrote:
> On Fri, Jun 24, 2011 at 09:23:28AM +0200, Julian Reschke wrote:
>>> I don't think this is an issue, because even if the server understands
>>> HTTP/1.10 as major=1, minor=10, it will just not know this version, and
>>> the draft states that such a version will not exist anyway since only
>>> one digit can be used for the minor.
>>
>> It won't know the version, but it doesn't need to, as 10>  1.
>
> Agreed as long as we don't change any minor semantics between 1.1 and 1.10
> (eg: the differences between 1.0 and 1.1 about persistent connections
> becoming default). If we decided that we'd go up to .10, the problem would
> suddenly arise that for many implementations, .10 would be matched as .1
> and appear lower as .2.
>
>>> In my opinion, it would be an issue if we had already used such a version,
>>> which is not the case. Even HTTP/0.9 was post-named with a single digit.
>>
>> True.
>>
>> So, summarizing: it *could* make existing implementations non-compliant,
>> but it really doesn't matter as there are no real-world HTTP messages
>> that are affected (like in "outside test cases").
>>
>> So we would:
>>
>> - simplify the ABNF (that's the whole point, right?)
>>
>> - adjust the prose
>>
>> - mark this as change from RFC 2616
>>
>> ?
>
> Yes that would seem the best solution.
> ...

OK, proposed patch at 
<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/273/273.diff>. 
The subsection 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 non-negative decimal digits
    separated by a "." (period or decimal point).  The first number
    ("major version") indicates the HTTP messaging syntax, whereas the
    second number ("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.

and the change log (B.2) would read:

    Clarify that the string "HTTP" in the HTTP-Version ABFN production is
    case sensitive.  Restrict the version numbers to be single digits due
    to the fact that implementations are known to handle multi-digit
    version numbers incorrectly.  (Section 2.5)

I also checked for examples that use multiple digits and couldn't find any.

Feedback appreciated,

Julian

Received on Friday, 24 June 2011 20:17:11 UTC