W3C home > Mailing lists > Public > public-appformats@w3.org > December 2007

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

From: Close, Tyler J. <tyler.close@hp.com>
Date: Thu, 20 Dec 2007 17:23:13 +0000
To: Ian Hickson <ian@hixie.ch>
CC: "public-appformats@w3.org" <public-appformats@w3.org>
Message-ID: <C7B67062D31B9E459128006BAAD0DC3D10BA6B70@G6W0269.americas.hpqcorp.net>

Hi Ian,

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.

--Tyler

> -----Original Message-----
> From: Ian Hickson [mailto:ian@hixie.ch]
> Sent: Wednesday, December 19, 2007 6:13 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:
> >
> > A simple proposal would be to send an OPTIONS request to
> "*" asking the
> > server if it understands your new Referer-Root header. If the answer
> > comes back "yes", let through any pending requests; otherwise, treat
> > them as they currently are. RFC 2616 contains language
> indicating that
> > this is the expected way for a client to probe a server's
> functionality.
> > Once you get back the yes, assumes it's the server's
> problem to figure
> > out what to do with cross-domain requests to particular resources.
> > Different servers can them implement their own internal
> rules for access
> > to different resources.
>
> Using OPTIONS was considered, but it's actually quite hard to
> make Apache
> respond to OPTIONS in author-controlled ways (and even more
> so if you have
> the php modules loaded, iirc).
>
> We want to have a solution that doesn't require changes to deployed
> servers. Authors should be able to implement this without
> contacting their
> existing hosting provider. Similarly, existing CMSes should be able to
> implement this and existing installations should be
> upgradeable without
> the servers having to be upgraded as well. The fear is that
> without this
> migration path, the feature won't be actually available for years. The
> perceived need for this feature is very great, so there's a lot of
> pressure to make it available as soon as possible.
>
> --
> Ian Hickson               U+1047E
> )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \
> _\  ;`._ ,.
> Things that are impossible just take longer.
> `._.-(,_..'--(,_..'`-.;.'
>
Received on Thursday, 20 December 2007 17:24:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:10:24 GMT