在Chrome 60中，XHR.getAllResponseHeaders（）不会像预期的那样返回标头 [英] XHR.getAllResponseHeaders() does not return headers as expected in Chrome 60

问题描述

在我们的web应用程序中，我们使用 XHR.getAllResponseHeaders（） - 函数来获取标题字段名称。我们使用 X-Access-Token 来接收我们在下一个请求中发送的JWT令牌以保持会话。从今天开始，登录后，每个下一个请求都会导致重定向返回到登录页面。

奇怪的是，Chrome只有这个问题，而不是Firefox或Safari 。这只是在我的电脑上，因为我的同事仍然可以登录，但我不能。

我们使用相同的软件，一些JavaScript，相同的一切，所以我们注意到它必须是我的浏览器。尝试重新安装并禁用了一些插件，但这并不重要。

我看起来像 XHR.getAllResponseHeaders（） code>函数返回错误的值，尽管我们从服务器发送了正确的值...任何人都知道为什么它不能工作了吗？


解决方案经过大量搜索，调试，测试和很多挫折后，我们终于发现Chrome 60中的标题字段名称与Chrome 59（在我的电脑上）转换为小写字母同事）名字保持不变。因此，头字段名称现在是 x-access-token ，而不是 X-Access-Token

对于那些在其javascript的某处使用 XHR.getAllResponseHeaders（）功能的用户，并且正在使用Chrome或其客户端：准备好补丁你的javascript以保持工作，因为自Chrome 60以来，XHR.getAllResponseHeaders（）函数现在只输出小写头字段名称！

有同样问题的人：
https：// twitter.com/thegecko/status/890346862875742210

@thegecko：Argg！ #Chrome 60在XHR.getAllResponseHeaders（）中强制标题名称为小写字母已打乱我！

另请参阅：
< a href =https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/_oxlCPNsrck =nofollow noreferrer> https://groups.google.com/a /chromium.org/forum/#!topic/blink-dev/_oxlCPNsrck ， https ：//github.com/whatwg/xhr/issues/146 和更新日志 https://chromium.googlesource.com/chromium/src/+/99c274ae8e7d366261dcfb89e0b98e733fb9d5f4

基于github和google小组的讨论，我们被警告说执行区分大小写的字符串比较可能是一件坏事。在upcomming HTTP / 2中，所有标题都是小写字母。因此，XHR规范在HTTP / 1.1中更改为小写所有标头。 Chrome（60）是第一个对此进行了修改的人，但Gecko / Firefox的补丁（ https ：//bugzilla.mozilla.org/show_bug.cgi?id=1370485 ）和Webkit / Safari已经可用了...

我们测试了一些东西使用一些简单的代码，但是当从我们的服务器发送头文件 Foo：Bar 时， XHR.getAllResponseHeaders（）功能（在Chrome 60中）将是`foo：Bar。

所以，为了让它在所有浏览器中都能正常工作，对响应的头字段名称执行不区分大小写的比较。这可以通过在处理标题之前使用 XHR.getAllResponseHeaders（）。toLowerCase（）来完成，或者使用不区分大小写的正则表达式，如 XHR .getAllResponseHeaders（）。match（/ foo / i）; 找到它们。

编辑：测试......我们发现使用 XHR.getResponseHeader（）也是从请求头获取值的安全方式。根据上面的例子，当发送头文件 Foo：Bar 时，如果使用 XHR.getResponseHeader（'Foo'）或 XHR.getResponseHeader（'foo'），都会输出值'Bar'。

针对 XHR的 MDN文档.getResponseHeader 证实了这一点：

搜索标题名称不区分大小写。

In our web-application, we use the XHR.getAllResponseHeaders()-function to fetch the header field names. We use the X-Access-Token to receive a JWT-token which we sent in the next request to keep session. Since today, after login in, each next request resulted in a redirect back to the login page.

Strangely enough, it was only Chrome having this problem, not Firefox or Safari. And it was only on my pc, because my colleague could still login while I couldn't.

We use the same software, some javascript, same everything, so we noted it has to be something with my browser. Tried a re-instal and disabling some plugins, but that didn't matter anything.

I looks like the XHR.getAllResponseHeaders() function returns the wrong values, although we send the right ones from the server... Anyone an idea why it isn't working anymore?

解决方案

After a lot of searching, debugging, testing and a lot of frustration we finally found out that the header field names in Chrome 60 where converted lowercase, in contract to Chrome 59 (on the pc of my colleague) where the names remained untouched. So the header field name was now x-access-token instead of X-Access-Token

For those who're using the XHR.getAllResponseHeaders()-function in their javascript somewhere, and are using Chrome, or their clients: Be prepared to have to patch your javascript in order to keep thing working, because since Chrome 60, the XHR.getAllResponseHeaders()-function now only output lowercase header field names!

Some guy with the same problem: https://twitter.com/thegecko/status/890346862875742210

@thegecko: Argg! #Chrome 60 forcing header names to be lowercase in XHR.getAllResponseHeaders() has broken me!

See also: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/_oxlCPNsrck, https://github.com/whatwg/xhr/issues/146 and the changelog at https://chromium.googlesource.com/chromium/src/+/99c274ae8e7d366261dcfb89e0b98e733fb9d5f4

Based on the discussion in the github and google groups, we were alerted that it's probably a bad thing to execute case-sensitive string compares. In the upcomming HTTP/2, all headers will be lowercase. Because of this, the XHR-specification changed to lowercase all their headers also in HTTP/1.1. Chrome (60) is the first one who changed this, but patches for Gecko/Firefox (https://bugzilla.mozilla.org/show_bug.cgi?id=1370485) and Webkit/Safari are already avaialble...

We tested things out with some simple code, but when sending the header Foo: Bar from our server, the output of XHR.getAllResponseHeaders()-function (in Chrome 60) will be `foo: Bar.

So, in order to get it working in all browsers and be future-proof: Make sure to execute a case-insensitive compare on the header field names from the response. This can be done very easily by using XHR.getAllResponseHeaders().toLowerCase() before handling the headers or by using a case-insensitive regexp like XHR.getAllResponseHeaders().match(/foo/i); to find them.

Edit: After more testing... we found out that using the XHR.getResponseHeader() is also a safe way of getting values from the header ofthe request. Based on the example above, when sending the header Foo: Bar, it doesn't matter if we use XHR.getResponseHeader('Foo') or XHR.getResponseHeader('foo'), both will output the value 'Bar'.

The MDN documentation for XHR.getResponseHeader confirms this:

The search for the header name is case-insensitive.

这篇关于在Chrome 60中，XHR.getAllResponseHeaders（）不会像预期的那样返回标头的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！