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

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:
>>> <>
>> 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. 
* 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?

Karl Dubost -
Developer Relations & Tools, Opera Software

Received on Wednesday, 29 June 2011 18:43:45 UTC