window.name作为数据传输:一种有效的方法？

Question

概述和原始问题

window.name是一只有趣的野兽。MDN的描述暗示了最初的意图：

窗口的名称主要用于设置超链接和窗体的目标。Windows不需要有名称。

因此，这意味着我们可以在此窗口中打开控制台，并编写：

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

然后...and让它通过弹出阻断器，它应该在一个名为"el“的窗口中打开google.com。由于相同的来源策略，我无法访问win的win属性，但是如果我在新窗口中打开一个控制台并键入name，我将得到"el goog"。

如果我将窗口发送回我打开的域(在本例中是stackoverflow.com)，我可以获得name属性，并且它没有改变。

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

这意味着通过设置窗口的name属性，我们可以拥有一种跨域会话存储。

如果google.com在窗口被发送回原始域之前更改了window.name的值，那么我们将看到新的值，而不是"el“。这可以用作跨域数据传输，在实用上类似于JSONP或CORS。

我做了一些搜索，试图找到更多的信息，显然dojo 认为这是合法的作为一种传输。不过，不知怎么的，这并不能让我完全放心。因此，我的问题是，有任何著名的网站使用window.name作为数据传输吗？我认为这很容易被发现，因为他们的文档会说：“在JSONP的查询字符串中添加‘回调’，或者为window.name添加‘任何东西’”，但我从来没有见过这样的东西。有人在野外发现过这个吗？

交替问题

也许没有人真正使用这种技术；如果这是真的，那么(正如罗布·W所指出的)上面的问题是无法回答的。所以，我的另一个问题是，这种方法有什么问题？这可能有助于解释为什么它没有真正被采纳。

在我看来，这种方法在JSONP上至少有两个好处。

• 使用JSONP，您可以信任来自国外的脚本在您的域中运行。使用window.name，恶意站点包含的任何脚本都将在自己的域中运行。
• 使用JSONP，无法传递大数据(对于URL来说太大的任何数据)，也无法生成HTTP POST。使用window.name，我们可以发布任意大小的数据。

缺点是什么？

示例实现

下面是一个非常简单的客户端实现示例。这不处理帖子请求，只处理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作为数据传输吗？

Answer 1

window.name不是特别好的传输，因为(AFAIK)当它更改时不会触发任何事件。因此，试图使用window.name作为双向通信通道的应用程序将不得不轮询它以获得更新。

至于真正使用它的网站，我从来没有听说过。可能有一些，但我只听过这种技术在纯理论意义上的讨论。

Answer 2

更重要的是，有人能给我一个明确的理由为什么我不应该使用winow.name作为数据传输吗？

当涉及到数据跨域传输时，window.name可能是一个真正的救星，但是它不能作为真正的通用数据传输机制的原因是缺少一个存储和检索数据的api。例如，localStorage提供了setItem，getItem。这样的api对于抽象实际存储的值和防止格式冲突(如果您端运行的不同库以不同的格式存储)是必要的。

据我所知，window.name还没有成为一种数据传输。我不知道我的看法是否准确(因此，原来的问题)，如果是的话，我想知道为什么会这样。

由于window.name没有提供这样的存储/检索抽象层--正如我前面所描述的--第三方librabries无法知道在window.main中存储数据时使用哪种格式，因此不会使用window.main，因为它是不可靠的。如果您(即您的主程序)是唯一读取或写入window.name的程序，您可以决定以json格式存储数据并相应地存储/检索数据。但是如果第三方库也想存储/检索一些东西，它决定不使用json，而是使用另一个多种序列化格式.这将意外地破坏您的json格式，并肯定会带来麻烦。