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: Mon, 31 Dec 2007 18:45:17 +0000
To: Anne van Kesteren <annevk@opera.com>, Ian Hickson <ian@hixie.ch>
CC: "public-appformats@w3.org" <public-appformats@w3.org>
Message-ID: <C7B67062D31B9E459128006BAAD0DC3D10C4E3B3@G6W0269.americas.hpqcorp.net>

Hi Anne,

When you say the current design means "no need to learn a lot of things", I think you are underestimating the complexity which currently consumes the bulk of the WG's recommendation. Just to be clear about how much simpler I believe this WG's rec could be, I believe the W3C's boilerplate "Status of this Document" section would be longer than the requirements section of a draft that used a design like the one I have proposed. This design can also have deployment characteristics that are better, even for early adopters, than the WG's currently proposed design.

For example, let's assume that current servers cannot be configured to respond in a customized way to a request to OPTIONS *. To avoid any update to server software, we'll instead use a hack like the robots.txt one. So:

1. Browser detects a cross-domain request
2. Browser sends GET request to /1234567890/Referer-Root
3. If server responds with a 200:
    - let through the cross-domain request, but include a Referer-Root header. The value of the Referer-Root header is the relative URL /, resolved against the URL of the page that produced the request. HTTP caching mechanisms should be used on the GET request of step 2.
4. If the server does not respond with a 200, reject the cross-domain request.

The string "/1234567890/" would be a long random number, specified in the rec, to avoid collision with any existing URL on the server.

The WG's work would then be done, and server and client developers could go their separate ways to work on their own software.

--Tyler

--
[1] "Access Control for Cross-site Requests"
    <http://www.w3.org/TR/access-control/>

> -----Original Message-----
> From: Anne van Kesteren [mailto:annevk@opera.com]
> Sent: Saturday, December 22, 2007 1:29 AM
> To: Ian Hickson; Close, Tyler J.
> Cc: public-appformats@w3.org
> Subject: Re: Comments on: Access Control for Cross-site Requests
>
> On Fri, 21 Dec 2007 23:10:33 +0100, Ian Hickson <ian@hixie.ch> wrote:
> >> 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.
> >
> > I'll leave that decision up to the spec's editor; I just wanted to
> > provide numbers to back up the earlier claim I made.
>
> I think the model is ok as it is now. It ties in with
> existing authoring
> practices (no need to learn a lot of things) and doesn't
> require an update
> of your server before you can use it. Given that a lot of
> authors really
> want this feature I'm quite convinced that clients (as in,
> Web browsers)
> will deploy releases with this implemented pretty quickly and
> therefore it
> will become usable in a few years. If that does not happen we can
> reevaluate.
>
>
> --
> Anne van Kesteren
> <http://annevankesteren.nl/>
> <http://www.opera.com/>
>
Received on Monday, 31 December 2007 18:47:12 GMT

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