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

 On Wed, 29 Jun 2011 14:40:40 -0400, Karl Dubost wrote:
> About versioning :)
>
> Le 21 juin 2011 à 21:10, Mark Nottingham a écrit :
>>> On Sun, Mar 27, 2011 at 10:26:18AM +0200, Mark Nottingham wrote:
>>>> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/273>
> […]
>>> Too many implementations I've seen just
>>> check for ver[7] == '1' or just memcmp(ver, "HTTP/1.1", 8).
>
> Definitely an issue. It has been one of the major pain points of the
> Opera Browser. It has less impact I believe in the world of servers
> but still.
>
> Opera has been the first browser to get two digits by going from
> "9.80" to "10.0", a few years ago. When this transition happened, the
> browser stopped working for a number of Web sites. Libraries were
> identifying the User-Agent version has "1" instead of "10" by 
> grabbing
> the first digit of the string.
>
> Opera had to revert and create a funky user agent string which is
> still used now. Th real version number is now at the end.
> User-Agent: Opera/9.80 (Macintosh; Intel Mac OS X 10.6.7; U; fr)
> Presto/2.9.168 Version/11.50
>
> You could think that with the quick evolution of numbering by Google
> Chrome, it would have solved the issue. Well not really, people have
> codepath such as Opera then version number. If Opera is switching to 
> a
> more reasonable string such as
>
> User-Agent: Opera/11.50 (Macintosh; Intel Mac OS X 10.6.7; U; fr)
> Presto/2.9.168
> Some old scripts might break and the new scripts will break too. User
> agent sniffing is evil
>
> Back to the HTTP version number, there is indeed chances it will 
> break.
>
> # Strategies:
>
> * Identity which are the most common libraries, programs which are
> likely to break
>   and working with the implementers before the release of HTTPbis.

 Definitely worthwhile regardless of any consensus here.
  "Every bug unreported kills a good idea somewhere."(c)

> * Not creating a new version at all, if we consider HTTPbis as just a
> fix of HTTP 1.1
> * Creating a version number which will not break in the current
> deployed codes
>
> # Questions
>
> * Are there products which really depends on the HTTP version number
> for interoperability?
> * If yes, in which ways
> * What are these products?

 Any software written to comply with RFC 2616 section 3.1 as published
 "
 caching proxies MUST, gateways MAY [...] upgrade the request to the 
 highest version they support. The proxy/gateway's response to that 
 request MUST be in the same major version as the request.

       Note: Converting between versions of HTTP may involve 
 modification
       of header fields required or forbidden by the versions involved.
 "

 So any compliant middleware will be relying on HTTP version numbers for 
 both client and server to map the hop-by-hop functionality, encoding, 
 and possibly content types in transit.

 AYJ

Received on Thursday, 30 June 2011 01:21:37 UTC