XHR.getAllResponseHeaders() does not return headers as expected in Chrome 60

Question

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?

Answer 1

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.