Re: Sub-origins

On Thu, Aug 29, 2013 at 7:23 PM, Daniel Veditz <dveditz@mozilla.com> wrote:

> On 8/29/2013 2:26 PM, Joel Weinberger wrote:
> > Perhaps I'm missing something, though. Brad, is this not a concern of
> > yours? How would we expect a legacy browser,  for example, to gracefully
> > handle a hash origin or http://foo$bar.com <http://bar.com> origin?
>
> When would a legacy browser see one of those? They won't understand the
> suborigin header themselves so they won't create any. The only times I
> can think of are if web-served scripts blindly pass such a thing to
> postMessage(). Either the legacy browser will barf on the malformed
> origin or it simply won't match the plain origin of the target window --
> the message isn't going to make it.
>
Good point. To summarize, a serialized origin+suborigin would only be
created by the browser anyway, so if the browser doesn't speak suborigin,
it won't ever see a serialized origin+suborigin because it wouldn't create
one.

I'm getting pretty sold on the serialization business, but I'm with Dev's
point that some of the simpler options seem a lot cleaner to me.

>
> Web apps that want to use suborigins will have to know which browsers
> support it somehow. Or not use the features that have no graceful
> fallback if legacy browsers just do what they've always done.
>
> Create a document.location.suborigin ?

Like Dev, I'm +1 to that. Good idea.

> Then if it's undefined sites can
> know not to use that format. For convenience that value could be the
> full serialized origin+suborigin in whatever format we come up with
> rather than just the suborigin string which probably isn't interesting
> on its own anyway.
>
> -Dan Veditz
>
>