Re: Question about origin serialization

What are the all the different string forms?  The two I'm aware of are:

1) postMessage's origin property
2) XHR's Origin header

It seems like (1) and (2) could be made the same (modulo the
ASCII-ness of the Origin header) by having postMesasge use the string
"null" instead of "" for non-host origins.  Also, I think the behavior
of file:// URLs is slightly different as (1) uses "file://" and (2)
uses "null", but that seems like it could also be synchronized.

Browser implementations won't be able to replace same-origin checks
with comparing these strings because of document.domain and because
most browsers contain a privileged security context which makes the
check asymmetric.  (Not to mention things like signed jars in
Mozilla.)

Adam


On Fri, Sep 26, 2008 at 6:01 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>
> Ian Hickson wrote:
>>
>> My understanding is that the specs now have just two functions (one for
>> ASCII and one for Unicode). Is this not the case?
>
> No, because various places in the spec rely on different behaviors for the
> non-triple origins.
>
>>> Fundamentally, by the way, that's what Access-Control seems to rely on...
>>
>> How so?
>
> It specifies that you stringify the origins and then compare the strings, so
> in the most direct possible way.
>
>> The benefits would have to be really great to start introducing new
>> standard syntax, IMHO. I'm a little concerned that we're putting the cart
>> before the horse here -- we need to prove a need before we solve it.
>
> Agreed.  I guess from my point of view as an implementor I'd rather not
> implement the spec as written than have 4+ stringification functions, which
> is where things seem to be headed right now....
>
> -Boris
>
>
>

Received on Saturday, 27 September 2008 09:16:14 UTC