window.name как транспорт данных: правильный подход?

Обзор и исходный вопрос

window.name — интересный зверь. Описание MDN намекает на первоначальное намерение:

Имя окна используется в основном для установки целей для гиперссылок и форм. Windows не обязательно должны иметь имена.

Итак, это означает, что мы можем открыть консоль в этом окне и написать:

var win = window.open('http://google.com', 'el goog');

...а затем пропустите его через блокировщик всплывающих окон, который должен открыть google.com в окне с именем el goog. Я не могу получить доступ к свойству name элемента win из-за той же политики происхождения, но если я открою консоль в новом окне и наберу name, я получу "el goog".

Если я отправлю окно обратно в домен, из которого я его открыл (в данном случае stackoverflow.com), я могу получить свойство name, и оно не изменилось.

win.location.replace(location.href);
win.name; // "el goog"

Это означает, что мы можем иметь своего рода междоменное хранилище сеансов, установив свойство name окна.

Если бы google.com изменил значение window.name до того, как окно было отправлено обратно в исходный домен, вместо el goog мы увидели бы новое значение. Это можно использовать в качестве междоменного транспорта данных, аналогичного JSONP или CORS.

Я немного поискал, чтобы найти больше информации, и, по-видимому, dojo считает, что это законно как транспорт. Впрочем, меня это как-то совсем не успокаивает. Итак, мой вопрос: используют ли какие-либо авторитетные сайты window.name в качестве транспорта данных? Я думаю, это будет легко заметить, потому что в их документах будет сказано что-то вроде добавить «обратный вызов» в строку запроса для JSONP или добавить «независимо» для window.name, но я никогда этого не делал. видел что-то подобное. Кто-нибудь действительно замечал это в дикой природе?

Альтернативный вопрос

Может случиться так, что никто на самом деле не использует эту технику; если это правда, то (как указал Роб В.) на поставленный выше вопрос нет ответа. Итак, мой альтернативный вопрос: какие проблемы с этим подходом? Это может помочь объяснить, почему он на самом деле не был принят.

На мой взгляд, у этого подхода есть как минимум два преимущества перед JSONP.

• С JSONP вы доверяете скрипту иностранного происхождения для запуска на вашем домене. С window.name любые сценарии, включенные вредоносным сайтом, будут выполняться в их собственном домене.

• С JSONP нет возможности передавать большие данные (что-то слишком большое для URL-адреса) и нет возможности сделать HTTP POST. С помощью window.name мы можем публиковать произвольные данные любого размера.

Каковы недостатки?

Пример реализации

Вот очень простой пример реализации клиента. Это не обрабатывает запросы POST, только 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);

});​

Я создал скрипт, чтобы протестировать его здесь. Он использует этот скрипт в качестве тестового сервера.

Вот немного более длинный пример, который может выполнять запросы POST: http://jsfiddle.net/n9Wnx/2/< /а>