Confirmed in Version Version 60.0.3112.78 (Offizieller Build) (64-Bit)

This is actually now required by the spec: https://xhr.spec.whatwg.org/#the-getallresponseheaders%28%29-method and Chrome was fixed to match the spec in M60 at  issue 716994 .  

A compat analysis was done that suggested the risk of breakage was low, I'm sorry to hear that your application was impacted.

Since we didn't learn about the breakage here until after the change hit Chrome stable, it's too late to do anything to prevent this from reaching the bulk of Chrome users (had the issue been filed while Chrome 60 was in beta we could have considered delaying).

The next version of Safari is expected to have this change (https://bugs.webkit.org/show_bug.cgi?id=169286) and Firefox has just changed as well (https://bugzilla.mozilla.org/show_bug.cgi?id=1348390).

Are you able to update your application to accommodate this change in browser behavior?

Unfortunately our application is not a website on the Internet that we can update and everyone gets the latest version.
Instead it is hosted by our customers themselves.

While it is already fixed for future releases it creates a lot of confusion among our customers right now since their existing installation suddenly doesn't work any more.

And since this is done according to the spec this change in behavior is unlikely to be reverted? So truth be told our application will stay broken for our Chrome users unless we provide a backport patch to them.
Or they switch to Firefox since there seems to be a flag(dom.xhr.lowercase_header.enabled=false) which can turn this behavior off when it is also live there.
So at least this mitigates the issue for existing installations a little. There is no such flag for Chrome?

In any case I would have loved to see a deprecation message in Chrome like for Selection.addRange()
"[Deprecation] The behavior that Selection.addRange() merges existing Range and the specified Range was removed. See https://www.chromestatus.com/features/6680566019653632 for more details."

Hi,
We are in the same case than Thomas.

We collect some csrf token in server response headers using some GWT 2.5.1 code.
GWT 2.5.1 uses XMLHttpRequest.getAllResponseHeaders() internally (see https://github.com/gwtproject/gwt/blob/2.5.1/user/src/com/google/gwt/http/client/ResponseImpl.java#L42)

Since headers are now lowercase when using chrome 60 this breaks completely our application which become unusable. This is a huge deal for us because we are an on-premises software, meaning that our product cannot be used anymore on Chrome by all our client for all already released version.

It seems weird to me that the spec changes suddenly, I would expect a stable behaviour at least for HTTP1 protocol

Thanks for the details, again I'm sorry to hear the pain this has caused you.  We have quite a substantial fraction of the Chrome user base using our beta builds, so combined with the compat analysis we did, when we heard no complaints about this during beta we expected that this change would be safe (but we know it's always very hard to tell - see https://bit.ly/blink-compat for some of the nuance on how we try to make such decisions).

Given that most of the major engines have already been changed for this, I think we need to involve them in this discussion.  Presumably it's ultimately not going to solve your problem if Chrome undoes this change but Firefox and Safari users are still broken.  I've filed https://github.com/whatwg/xhr/issues/146 with the standards group to discuss it further, feel free to weight in there with why you feel this specification change was a mistake.

Thomas, you mentioned the Firefox pref.  If we added an entry to chrome://flags in Chrome 61+ to go back to the old behavior, to what extent would that help mitigate the problem?  tyoshino@ any concerns with adding such a flag as a temporary mitigation while we try to figure out the compat situation here?

Also, any data you can give us on the scope of impact would be helpful (eg. how many users).

We could also explore if there's anything we could do to make it easier to patch your older versions to handle this.  Eg. if we added an API option to disable the lowercasing would that be easier for you than just updating the code to handle it?  I assume you've got some (albeit probably painful) way to get emergency patches out to the deployed software (eg. in the case of a major security hole), right?

By the way:

> In any case I would have loved to see a deprecation message in Chrome like for Selection.addRange()

Yes that is our standard practice for almost all breaking changes.  Unfortunately it wasn't the right choice for this change because our compat analysis showed that virtually all callers of this API continued to work fine when getting lowercased values.  As a result, generating a warning whenever the API was called would cause more damage (in terms of training people to ignore such warnings as generally useless - a real problem in practice) than benefit.

 Issue 749680  has been merged into this issue.

There have been no changes to Blink or the spec since this bug was filed, and it doesn't look like we'll be doing anything either.