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

AltStyle によって変換されたページ (->オリジナル) /