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

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

本文关键字：一种 有效 方法 name 数据传输 window      更新时间：2023-09-26

概述和原始问题

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

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

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

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

。然后让它通过弹出窗口阻止程序，它应该在名为"el Goog"的窗口中打开 google.com。 由于同源策略，我无法访问win的name属性，但是如果我在新窗口中打开控制台并键入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 添加'whatever'"，但我从未见过这样的事情。有没有人在野外发现过这个？

<小时 />

替代问题

可能没有人真正使用这种技术;如果这是真的，那么(正如Rob W指出的那样(上面的问题是无法回答的。所以，我的替代问题是，这种方法有什么问题？这可能有助于解释为什么它没有真正被采用。

在我看来，这种方法与 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作为数据传输？

window.name作为

传输工具并不是特别好，因为(AFAIK(它在更改时不会触发任何事件。因此，尝试将window.name用作双向通信通道的应用程序将不得不轮询其更新。

至于实际使用它的网站：我从未听说过。可能有一些，但我只听说过在纯粹的理论意义上讨论过这种技术。

更重要的是，谁能给我一个充分的理由，为什么我不应该使用 winow.name 作为数据传输？

虽然在跨域更改传输数据时，window.name可以成为真正的救星，但它不能用作真正的通用数据传输机制的原因是由于缺乏用于存储和检索数据的 API。例如localStorage提供setItem、getItem。这样的 API 对于从值的实际存储方式中抽象出来并防止格式冲突是必要的(如果您端运行的不同库以不同的格式存储，就会出现格式冲突(。

据我所知，window.name 并没有作为一种数据传输而流行起来。我想知道我的看法是否准确(因此是最初的问题(，如果是这样，我想知道为什么会这样。

由于window.name没有提供这样的存储/检索抽象层 - 如我上面的观点所述 - 第三方库在window.main中存储数据时无法知道使用哪种格式，因此永远不会使用window.main因为它不可靠。如果您(即您的主程序(是唯一读取或写入window.name则可以决定以 json 格式存储数据并相应地存储/检索。但是，如果第三方库也想存储/检索某些内容并且决定不使用 json，而是使用众多序列化格式中的另一种......这会意外破坏您的 JSON 格式，肯定会造成麻烦。

相关文章：