Re: [suborigins] serializing of origins

The serialized origin also makes an appearance in the Origin header in
cross-domain XHRs and fetches. But, yes, I think the big driver of the
particular syntax is being safe with with origin-checking content that is
not aware of suborigins.

Are you not happy with the specific syntax or the general idea of extending
the origin string to include an additional element?

The serialization does seem clunky, but I'm not sure the alternative are
very much better.

> Hey all,
>
> I started to look at our suborigin implementation in blink, and one of the
> things I was stumbling over was the serialization of an origin with a
> suborigin, i.e. (scheme, host, port, suborigin) getting serialized to
> ${scheme}-so://${suborigin}.${host}:${port}/
>
> It seems that the main reason for doing this is to break postMessage for
> code that is not aware of suborigins. Is that the case?
>
> If that was the case, have we considered other ways to break this, e.g.
> make origin return the null value and add instead a new property to message
> (e.g. initiator with two properties origin and suborigin)?
>
> best
> -jochen
>
>