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

On 2011-06-25 10:39, Julian Reschke wrote:
> ...
> 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

...applied with <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1313>.

Best regards, Julian

Received on Monday, 27 June 2011 11:42:23 UTC