W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2011

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

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Thu, 30 Jun 2011 13:20:52 +1200
To: <ietf-http-wg@w3.org>
Message-ID: <fc1ffea0572f596c1a4047c7bd515170@treenet.co.nz>
 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 
       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.

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

This archive was generated by hypermail 2.3.1 : Thursday, 1 October 2015 05:36:46 UTC