Обзор и исходный вопрос
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.
Я немного поискал, чтобы попытаться найти больше информации, и, по-видимому, додзё считает, что это законныйтранспорт.Но как-то это меня не совсем успокаивает. Итак, мой вопрос: используют ли авторитетные сайты 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/
Резюме
Насколько я могу судить, window.name
не прижился как транспорт данных. Интересно, правильно ли мое восприятие (отсюда исходный вопрос), и если да, то интересно , почемуэто так. Я перечислил несколько преимуществ, которые window.name
имеют по сравнению с JSONP. Может ли кто-нибудь определить некоторые недостатки, которые могли помешать внедрению этого метода?
Более конкретно, может ли кто-нибудь дать мне вескую причину, почему я не должен использовать winow.name
в качестве транспорта данных?