Subject: Re: wrt HTTP Origin header serialization (was Re: The HTTP Sec-From Header (draft-abarth-origin))

From: =JeffH <[email-masked]>
Date: Wed, 28 Oct 2009 11:27:24 -0700

> The syntax was chosen to match the HTML postMessage API, which has
 > shipped in all major browsers.  I think it's unlikely we'll change the
 > syntax now without a very compelling reason.

hm, I was afraid of that.

 > More seriously, whether or not it looks like a URI, it's not a URI.

well, that's your intent, but *syntactically* it's a URI (perhaps even an 
invalid URI if the scheme profile doesn't spec having "://" as a component).

Also, it appears the Gecko window.postMessage() method documentation denotes it 
as a URI..

   Gecko DOM Reference - window.postMessage
   https://developer.mozilla.org/en/DOM/window.postMessage

   " targetOrigin
       Specifies what the origin of otherWindow must be for the event to be
       dispatched, either as the literal string "*" (indicating no preference)
       or as a URI."

In terms of why this is subtle-but-perhaps-important, there's the case of some 
folks in the XML and Web world believing that one can use "http"-scheme based 
URIs as identifiers for arbitrary things that may not necessarily exist online, 
i.e. they are not dereferecable.

On the surface this would seem to not be a big deal, but it apparently is 
causing (at least) the W3C systems folk some grief because there's some 
software out there  that behaves thus: "if it looks like an http URI, 
dereference it". (this is apparently putting some non-trivial load on W3C 
servers for > 2 yrs now).

Here's a couple notes about this phenomenon..

Re: HTTP 503 Error
http://lists.w3.org/Archives/Public/site-comments/2009Jun/0009.html

W3C's Excessive DTD Traffic
http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic

All the above fyi/fwiw.

=JeffH

ps:

So I'm just guessing here that window.postMessage() was (initially) crafted the 
way it is because they wanted the programmer to be able to just pass it the URI 
at hand, whose 'origin' they wished to 'state', without parsing the URI to 
extract the origin.

Tho, presummably if a browser impl has a URL handling interface, like Chrome 
does (GURL), and already has a getOrigin() method (as Chrome apparently does 
[1] -- getOrigin() used in postMessage() impl), then updating the origin 
serialization could ostensibly be accomplished....  (whether or not serialized 
origins are scrawled down in persistent data anwhere  would of course 
complicate things) ... tho this list isn't the place to discuss impl details.

[1] chrome postMessage() impl
http://src.chromium.org/viewvc/chrome/trunk/src/chrome/renderer/external_host_bindings.cc?view=markup

---
end

---

From: Adam Barth <[email-masked]>
Date: Thu, 29 Oct 2009 14:43:30 -0700

On Wed, Oct 28, 2009 at 11:27 AM, =JeffH <[email-masked]> wrote:
> Also, it appears the Gecko window.postMessage() method documentation denotes
> it as a URI..
>

The targetOrigin parameter actually *is* a URI.  I meant the origin
property of the MessageEvent.

> servers for > 2 yrs now).

That problem is caused by putting these URI in documents stored on
servers.  Here we're sending the string from the client to the server.
 Don't we already have this problem for Referer?  It doesn't seem like
that big a deal in this case.

> So I'm just guessing here that window.postMessage() was (initially) crafted
> the way it is because they wanted the programmer to be able to just pass it
> the URI at hand, whose 'origin' they wished to 'state', without parsing the
> URI to extract the origin.

That's correct for targetOrigin, but not for the origin property of
MessageEvent.  The syntax for the origin property was chosen to
compactly package the scheme and the host in a familiar form.  It's
possible we should have used something else, but that's water under
the bridge at this point.

> serialization could ostensibly be accomplished....  (whether or not
> serialized origins are scrawled down in persistent data anwhere  would of
> course complicate things) ... tho this list isn't the place to discuss impl
> details.

Regardless, there are lots of web sites that depend on the particular
serialization we already shipped for postMessage.  The benefits of
adding a new, different serialization here don't seem to out-weigh the
costs.

Adam