window.name as a data transport: a valid approach?
Overview and original question
window.name is an interesting beast. MDN's description hints at the original intent:
The name of the window is used primarily for setting targets for hyperlinks and forms. Windows do not need to have names.
So, this means we can open the console in this window, and write:
var win = window.open('http://google.com', 'el goog');
...and then let it through the popup blocker, that should open google.com in a window named "el goog." I can't access the name property of win because of the same-origin policy, but if I open a console in the new window and type name, I'll get "el goog".
If I send the window back to the domain I opened it from (in this case stackoverflow.com), I can get the name property, and it hasn't changed.
win.location.replace(location.href);
win.name; // "el goog"
This means we can have a kind of cross-domain session store by setting the name property of a window.
If google.com had changed the value of window.name before the window was sent back to the original domain, we'd see the new value instead of "el goog." This could be used as a cross-domain data transport, similar in utility to JSONP or CORS.
I did a bit of searching to try to find more info, and apparently dojo thinks it's legit as a transport. Somehow, though, that doesn't completely reassure me. So my question is, are any reputable sites using window.name as a data transport? I'd think it would be easily spotted, because their docs would say something like "add 'callback' to the query string for JSONP, or add 'whatever' for window.name," but I've never seen anything like that. Has anyone actually spotted this in the wild?
Alternate question
It may be the case that nobody is really using this technique; if that's true then (as Rob W pointed out) the question above is unanswerable. So, my alternate question is, what are the problems with this approach? This might help explain why it hasn't really been adopted.
As I see it, there are at least two benefits to this approach over JSONP.
With JSONP, you trust a script from a foreign origin to run on your domain. With
window.name, any scripts included by a malicious site would run on their own domain.With JSONP, there is no way to pass in big data (anything too big for a URL), and no way to make an HTTP POST. With
window.name, we can post arbitrary data of any size.
What are the drawbacks?
Example implementation
Here is a very simple example of a client implementation. This doesn't handle POST requests, only GET.
function fetchData(url, callback) {
var frame = document.createElement('iframe');
frame.onload = function() {
frame.onload = function() {
callback(frame.contentWindow.name);
frame.parentNode.removeChild(frame);
}
frame.src = 'about:blank';
}
frame.src = url;
document.body.appendChild(frame);
}
// using it
fetchData('http://somehost.com/api?foo=bar', function(response) {
console.log(response);
});
I've set up a fiddle to test it out here. It uses this script as a test server.
Here is a slightly longer example that can make POST requests: http://jsfiddle.net/n9Wnx/2/
Summary
As far as I can tell, window.name has not caught on as a data transport. I wonder if my perception is accurate (thus the original question) and if so, I wonder why this is the case. I've listed a few advantages that window.name seems to have over JSONP. Can anyone identify some disadvantages that might have contributed to preventing adoption of this technique?
More to the point, can anyone give me a solid reason why I shouldn't use winow.name as a data transport?
Answer
window.name isn't particularly good as a transport, as (AFAIK) it doesn't fire any events when it's changed. As a result, an application which was trying to use window.name as a two-way communications channel would have to poll it for updates.
As far as sites that actually use it: I've never heard of any. There might be some, but I've only heard this technique discussed in a purely theoretical sense.