- From: =JeffH <Jeff.Hodges@KingsMountain.com>
- Date: Wed, 28 Oct 2009 11:27:24 -0700
- To: HTTP Working Group <ietf-http-wg@w3.org>
> 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
Received on Wednesday, 28 October 2009 18:33:55 UTC