On Fri, 20 Feb 2009 19:36:47 +0100, Bil Corry <[email protected]> wrote:

Sigbjørn Vik wrote on 2/20/2009 8:46 AM:
One proposed way of doing this would be a single header, of the form:
x-cross-domain-options: deny=frame,post,auth; AllowSameOrigin;
allow=*.opera.com,example.net;
This incorporates the idea from the IE team, and extends on it.

Have you taken a look at ABE?

        http://hackademix.net/wp-content/uploads/2008/12/abe_rules_03.pdf

I am not quite certain what you are referring to, the document is a ruleset for 
how to express what is allowed and disallowed. Do you mean that clients should 
be using a URL list, or that servers should be using this particular grammar to 
decide which headers to send with their URLs?
For a domain wide policy file a document like this might work well though.

For cross-domain resources, this means that a browser would first have
to make a request with GET and without authentication tokens to get the
x-cross-domain-options settings from the resource. If the settings
allow, a second request may be made, if the second request would be
different. The result of last request are handed over to the document.

Have you considered using OPTIONS for the pre-flight request, similar to how Access Control for Cross-Site Requests does it?

        http://www.w3.org/TR/access-control/#cross-site2

Good point. Trying to use OPTIONS for existing servers might break them, a GET 
might be safer. Then again, OPTIONS shouldn't break anything, GETs might have 
side-effects where OPTIONS don't, and an OPTIONS reply typically has a much 
smaller payload than a GET reply. In the case of a reply to a pre-flight 
request where the user agents has cookies but the server replies that contents 
are the same with or without cookies, an OPTIONS request would require two 
requests, a GET only one. OPTIONS is probably more in the spirit of HTTP though.

Either could work, the idea is the same. Which would be better would have to be 
researched empirically, but OPTIONS might be the better candidate.

--
Sigbjørn Vik
Quality Assurance
Opera Software


Reply via email to