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?

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.

More to the point, can anyone give me a solid reason why I shouldn't use winow.name as a data transport?

While window.name can be a true saviour when it comes to transporting data accross domain changes, the reason it cannot be used as real universal data transport mechanism is due to the lack of an api to store and retrieve data. For example localStorage provides setItem, getItem. Such an api is necessary to abstract from how values are actually stored and to prevent format clashes (which would arise if different libraries running on your side would store in different formats).

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.

Since window.name does not provide such a store/retrieve abstraction layer – as described in my point above – 3rd-party librabries cannot know which format to use when storing data in window.main and hence will never use window.main as it is unreliable. If you (i.e. your main program) were the only one reading from or writing to window.name you could decide to store data in json format and store/retrieve accordingly. But what if a 3rd-party library also wanted to store/retrieve something and it decided not to use json and instead go with another of the numerous serialization formats... this would accidentally break your json format and definitely cause trouble.

window.name as a data transport: a valid approach?

Related

Recent Posts