XHR.getAllResponseHeaders() 在 Chrome 60 中未按预期返回标头

XHR.getAllResponseHeaders() does not return headers as expected in Chrome 60(XHR.getAllResponseHeaders() 在 Chrome 60 中未按预期返回标头)
本文介绍了XHR.getAllResponseHeaders() 在 Chrome 60 中未按预期返回标头的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着跟版网的小编来一起学习吧!

问题描述

在我们的 Web 应用程序中,我们使用 XHR.getAllResponseHeaders() 函数来获取标头字段名称.我们使用 X-Access-Token 来接收我们在下一个请求中发送的 JWT-token 以保持会话.从今天开始,登录后,每个下一个请求都会导致重定向回登录页面.

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.

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

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.

我们使用相同的软件,一些 javascript,一切都相同,所以我们注意到它必须与我的浏览器有关.尝试重新安装并禁用一些插件,但这并不重要.

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.

我看起来像 XHR.getAllResponseHeaders() 函数返回了错误的值,尽管我们从服务器发送了正确的值...有人知道为什么它不再工作了吗?p>

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?

推荐答案

经过大量搜索、调试、测试和很多挫折,我们终于发现 Chrome 60 中的 header 字段名称转换为小写,合同为Chrome 59(在我同事的电脑上),名字保持不变.所以标题字段名称现在是 x-access-token 而不是 X-Access-Token

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

对于那些在某个地方的 javascript 中使用 XHR.getAllResponseHeaders() 函数并使用 Chrome 或他们的客户端的人:准备好必须修补您的 javascript 以保持工作正常,因为从 Chrome 60 开始,XHR.getAllResponseHeaders() 函数现在只输出小写标题字段名称!

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!

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

@thegecko:阿格!#Chrome 60 在 XHR.getAllResponseHeaders() 中强制标头名称为小写字母让我心碎!

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

另请参阅: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 小组中的讨论,我们被警告说执行区分大小写的字符串比较可能是一件坏事.在即将到来的 HTTP/2 中,所有标头都是小写的.因此,XHR 规范在 HTTP/1.1 中也将其所有标头都更改为小写.Chrome (60) 是第一个改变这一点的,但是 Gecko/Firefox 的补丁 (https://bugzilla.mozilla.org/show_bug.cgi?id=1370485) 和 Webkit/Safari 已经可用...

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...

我们使用一些简单的代码进行了测试,但是当从我们的服务器发送标头 Foo: Bar 时,XHR.getAllResponseHeaders()-function 的输出(在Chrome 60) 将是 `foo: Bar.

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.

因此,为了使其在所有浏览器中都能正常工作并永不过时:确保对响应中的标头字段名称执行不区分大小写的比较.这可以通过在处理标头之前使用 XHR.getAllResponseHeaders().toLowerCase() 或使用不区分大小写的正则表达式(如 XHR.getAllResponseHeaders().match(/foo) 轻松完成)/i); 找到它们.

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.

经过更多测试...我们发现使用 XHR.getResponseHeader() 也是一种从请求标头获取值的安全方法.根据上面的例子,当发送 header Foo: Bar 时,我们使用 XHR.getResponseHeader('Foo') 还是 XHR 都没有关系.getResponseHeader('foo'),两者都会输出值'Bar'.

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'.

MDN 文档XHR.getResponseHeader 证实了这一点:

The MDN documentation for XHR.getResponseHeader confirms this:

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

The search for the header name is case-insensitive.

这篇关于XHR.getAllResponseHeaders() 在 Chrome 60 中未按预期返回标头的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持跟版网!

本站部分内容来源互联网,如果有图片或者内容侵犯了您的权益,请联系我们,我们会在确认后第一时间进行删除!

相关文档推荐

ajax请求获取json数据并处理的实例代码 $.ajax({ type: 'GET', url: 'https://localhost:44369/UserInfo/EditUserJson',//请求数据 data: json,//传递数据 //dataType:'json/text',//预计服务器返回的类型 timeout: 3000,//请求超时的时间 //回调函数传参 suc
在开发JS过程中,会经常遇到两个小数相运算的情况,但是运算结果却与预期不同,调试一下发现计算结果竟然有那么长一串尾巴。如下图所示: 产生原因: JavaScript对小数运算会先转成二进制,运算完毕再转回十进制,过程中会有丢失,不过不是所有的小数间运算会
问题描述: 在javascript中引用js代码,然后导致反斜杠丢失,发现字符串中的所有\信息丢失。比如在js中引用input type=text onkeyup=value=value.replace(/[^\d]/g,) ,结果导致正则表达式中的\丢失。 问题原因: 该字符串含有\,javascript对字符串进行了转
Rails/Javascript: How to inject rails variables into (very) simple javascript(Rails/Javascript:如何将 rails 变量注入(非常)简单的 javascript)
Rails 3.1 ajax:success handling(Rails 3.1 ajax:成功处理)
CoffeeScript always returns in anonymous function(CoffeeScript 总是以匿名函数返回)