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

It seems like we should have numbers about the upgrade cycle for the dominant client, Internet Explorer, before it is reasonable to draw any conclusions. The same reference you used for Firefox and Opera reports the following for IE:

IE6: 40.24%
IE7: 36.84%

And that's for the *total browser market*, not of IE's share of the market.

So the dominant client is one which is out of date. And that's with the benefit of a major operating system release in favour of the new client. I don't think there's another major OS release planned within the next couple years, so at best IE7 looks to stick around for several years.

The other issues you raise seem more like social ones. I think it makes sense to reach out to the Apache developers to get their opinion on this decision before going with the much more complicated design. Taking on all the complexity of a policy language, and having the policy enforcement party be different from the policy setting party, is a huge cost to pay. I think the WG must be absolutely certain that requiring a server change will delay adoption of the feature for years, before accepting these costs. I still suspect the server deployment time will be hidden by the client deployment time. For me, the likely scenario is that developers wait until client deployment crosses some threshold, and then they upgrade their servers and deploy new applications.

--Tyler

> -----Original Message-----
> From: Ian Hickson [mailto:ian@hixie.ch]
> Sent: Thursday, December 20, 2007 9:06 PM
> To: Close, Tyler J.
> Cc: public-appformats@w3.org
> Subject: 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 17:42:49 UTC