Re: [access-control] Update

(In which I reply to three e-mails at once...)

On Thu, 10 Jul 2008 13:10:54 +0200, Jonas Sicking <jonas@sicking.cc> wrote:
> Anne van Kesteren wrote:
>>  Let me know how that works out. postMessage() is shipping already in  
>> various implementations...
>
> I will keep you updated.
>
> Until then I very strongly feel we need to change the parsing rules to  
> refer to rfcs 3986 and 3490 the way the previous draft did.

Well, we no longer need wildcarding, etc. We certainly could limit the  
syntax, but I don't think it makes sense to make this inconsistent with  
postMessage(..., targetOrigin).


>>>>> Additionally, the way the spec was written before we could create a  
>>>>> conformat implementation now without having to worry about HTML5  
>>>>> changing things under us.
>>>>
>>>> Well, in the end we want all those concepts implemented in the same  
>>>> way everywhere, right? So I'm not sure how this matters.
>>>
>>> So why not let HTML5 refer to Access-Control?
>>
>>  I don't really see how that would work.
>
> Access-Control can define how to parse the 'origin' part of the URI and  
> HTML5 can refer to that. Or they can both refer to the same RFCs.

We have more in common than just parsing a URL. E.g., serializing an  
origin, origin itself, same origin matching.


On Thu, 10 Jul 2008 13:14:03 +0200, Jonas Sicking <jonas@sicking.cc> wrote:
> An alternative syntax I've been thinking about for opting in to cookies  
> is:
>
> Access-Control: allow-with-credentials <http://foobar.com>
>
> There are a couple of advantages to this syntax. First of all it keeps  
> down the number of headers. Second, and more importantly, it cleanly  
> disallows opting in to cookies while wildcarding. We'd simply make the  
> syntax for the header
>
> Access-Control: "Access-Control" ":" allow-rule | allow-with-cred-rule
> allow-rule: "allow" "<" (URL | "*") ">"
> allow-with-cred-rule: "allow-with-credentials" "<" URL ">"

We tried overloading Access-Control before with "allow this URL" and  
"allow this method". That didn't turn out so well.


> One, albeit not big, issue with the current proposal is that it allows  
> someone to say.
>
> Access-Control-Origin: *
> Access-Control-Allow-Credentials: true
>
> which is somewhat unfortunate. While this can be defined to be rejected  
> by an implementation that supports the Access-Control-Allow-Credentials  
> header. An implementation like XDR which doesn't will still allow the  
> syntax.

A problem with this approach is that if a resource exposes both public and  
private data you need an additional request header to know whether or not  
the allow-with-credentials syntax is actually supported and do more  
conditional logic on the server. (Or require that every client supports  
the credentials syntax but does not necessarily support sending  
credentials...)

Keeping these as separate headers makes more sense to me, unless we start  
merging all the response headers together somehow which seems like a bad  
idea as it makes things more complex (way more complex values).


On Thu, 10 Jul 2008 13:17:29 +0200, Jonas Sicking <jonas@sicking.cc> wrote:
> To make it clear, since i'll be on vacation and won't be very responsive  
> on email the coming week, the current syntax is not acceptible to  
> mozilla. If referring to the above rfcs is not an option for some  
> reason, we need to define the syntax in some other way that disallows  
> full uris that includes paths.

I don't understand why it's not acceptible. You just shipped Firefox 3  
which uses exactly this syntax for more or less the same purpose.

(I will also be going on vacation soonish for what it's worth. 17 Jul - 6  
Aug.)


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Received on Thursday, 10 July 2008 21:05:26 UTC