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 01:59:12 +0000
To: Ian Hickson <ian@hixie.ch>
CC: "public-appformats@w3.org" <public-appformats@w3.org>
Message-ID: <C7B67062D31B9E459128006BAAD0DC3D10BA65C7@G6W0269.americas.hpqcorp.net>

Hi Ian,

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.

--Tyler

> -----Original Message-----
> From: Ian Hickson [mailto:ian@hixie.ch]
> Sent: Wednesday, December 19, 2007 5:32 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 significant portion of the proposal is devoted to
> specifying a policy
> > language for determining whether or not a page from a
> particular "root
> > URI" should be allowed to issue a cross-domain request to a
> particular
> > server. I think the problem can be solved without the server and the
> > client software agreeing on such a policy language. For
> example, rather
> > than have the server specify the rules for cross-domain requests and
> > have the client enforce these rules, the client should
> simply send the
> > request information to the server and have the server
> enforce its own
> > rules. I see no advantage to placing this logic in the client, as
> > opposed to the server. Placing the logic in the client introduces
> > significant complexity which creates many opportunities for
> > implementation bugs, specification ambiguity and
> misunderstanding by web
> > application developers, while possibly limiting the kinds
> of policies a
> > server can enforce.
>
> Interesting idea... can you propose a way of doing this that
> defaults to
> all-access-disabled,
> no-requests-other-than-GET-get-sent-without-approval
> for implementations and servers that don't implement the proposal?
>
> --
> Ian Hickson               U+1047E
> )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \
> _\  ;`._ ,.
> Things that are impossible just take longer.
> `._.-(,_..'--(,_..'`-.;.'
>
Received on Thursday, 20 December 2007 02:07:25 GMT

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