RE: Comments on: Access Control for Cross-site Requests

On Thu, 20 Dec 2007, Close, Tyler J. wrote:
> 
> What evidence do you have that the upgrade cycle for servers is slower 
> than the upgrade cycle for clients? It's always been my experience that 
> it's easier to upgrade a server than all its clients. If the upgrade 
> cycle for clients is indeed longer than it is for servers, your argument 
> is not persuasive.

Good question.

To answer it, I did a survey of about 100,000,000 pages (selected from 
Google's index, weighted by a rough approximation of what Google 
algorithmically thinks is most important), to see what the distribution of 
servers is on the Web (based on the Server: header).

Note that these numbers count _pages_, not hosts -- a specific host that 
happens to have many pages in the sample will have the scores 
proportionally weighted in its favour. This is the same technique as I 
have used in other studies, e.g. when determining the relative importance 
of tag names based on class name frequency in the design of HTML5.

Also note that many servers don't report actual version numbers, and that 
many servers report quite bogus data in general, which is why the numbers 
below don't always add up to 100%.

Looking at the big servers:

   Apache 2.x: 35% of Apache share
   Apache 1.x: 23% of Apache share

   Microsoft-IIS 6.0: 82% of IIS share
   Microsoft-IIS 5.0: 18% of IIS share

Both for Apache and IIS, around 20% of the market is running at least one 
major release behind. Apache 2 came out in 2002, IIS 6 came out about a 
year later in 2003. (There are only two major browsers in the market. We 
are assuming here that they would both quickly implement whatever solution 
was developed for cross-site XMLHttpRequest.)

Now let's look at the share by version for Firefox and Opera, as given by 
the reports on marketshare.hitslink.com:

   Firefox 2.0: 93% of Firefox share
   Firefox 1.5: 4% of Firefox share

   Opera 9.x: 98% of Opera share

Firefox 2 came out about a year ago in late 2006. Opera 9.0 came out in 
mid 2006.

Thus we see that browsers, over a much shorter time period, upgraded a 
much broader proportion of their installed base.

In addition, we have to consider how long it would take for server 
developers and client developers to actually release software that 
supported the new features.

The earlier proposal in this thread involved allowing servers to have 
custom responses in return to OPTIONS requests, something that relies on 
CGI scripts being invoked in response to OPTIONS requests. This was not 
possible in Apache for a long time. That particular issue was originally 
noticed in August 1996 [1], then reported in May of 1999 [2], and reraised 
in December 2002 [3], before being fixed in October 2005 [4], more than 
nine years after the issue was first found.

On the other hand, the client developers are actively involved in this 
working group, and are already implementing the new feature in pre-release 
browsers. It is likely that the features could be available in client 
browsers very shortly after the spec was ready -- probably in a matter of 
months for the first browsers to support the feature, not years.

I think that based on the numbers above, it is reasonably safe to assume 
that the upgrade cycle for servers is slower than the upgrade cycle for 
clients. I think it is also safe to assume that client developers would 
have software ready to be upgraded sooner than server developers would.

-- References --
[1] http://mail-archives.apache.org/mod_mbox/httpd-dev/199608.mbox/%3c9608132318.aa12603@paris.ics.uci.edu%3e
[2] http://www.mail-archive.com/apache-bugdb@apache.org/msg12727.html
[3] http://issues.apache.org/bugzilla/show_bug.cgi?id=15242
[4] http://issues.apache.org/bugzilla/show_bug.cgi?id=15242#c10

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Friday, 21 December 2007 05:06:08 UTC