Possible workaround from one of our team - however, this needs to be done on Chrome for end-user to mitigate the issue:

(function hotfix(){
    var currentDef = YAHOO.webui.AJAXValidator.success.toString();
    var fixedDef = '('.concat(currentDef.replace("getResponseHeader['Content-Type']", "getResponseHeader['content-type']"), ')');
    var fixedFn = eval(fixedDef);
    YAHOO.webui.AJAXValidator.success = fixedFn;
})()

This may have something to do with a change to the native function: XMLHttpRequest.prototype.getAllResponseHeaders

On firefox, the headers are returned capitalized. On chrome, they are not capitalized, despite the server sending them as capitalized. 

Server sends capitalized headers

Object of type 'XMLHttpRequest' calls method 'getAllResponseHeaders', and gets uncapitalized headers in response.

Deleted: XMLHttpRequest.PNG 58.6 KB

	XMLHttpRequest.PNG 58.6 KB View Download

robsherw.cisco@, thank you for the report. Can you please provide a sample test case to triage this issue further?

The underlying problem seems to be in the XMLHttpRequest.

If you go to https://www.w3.org/ and open the javascript console, and run:

(function(){
    var xhr = new XMLHttpRequest();
    xhr.open('GET', '/', true);
    xhr.onload = function echoHeaders(){
        console.log("%o", xhr.getAllResponseHeaders());
    };
    xhr.send();
    return xhr;
})();

You can see that the headers are returned lowercase. They should be capitalized, as the server sends capitalized headers. 

Deleted: FundamentalError-HeadersAreLowercase.png 218 KB

	FundamentalError-HeadersAreLowercase.png 218 KB View Download

I have a temporary workaround; but it would be nice if this were fixed in the native function definition

Deleted: Chrome60--Override--XMLHttpRequestMethod.js 1.2 KB

Chrome60--Override--XMLHttpRequestMethod.js 1.2 KB View Download

@manoranj - what further information do you require for a "sample test case" outside of what Charles and I have chimed in on so far?

Thx,
Robert

c#5 seems to be helpful.

This also applies to the web ui for the web sec appliance (WSA), exactly the same issue as ESA. I confirmed that workaround also works for WSA from #1 comment. 

We can confirm, having same issue with SMA, ESA and WSA (M680, S680, S380, C380).

Current version of Chrome: Version 60.0.3112.78 (Official Build) (64-bit)
Older version tested against: Version 53.0.2785.89

I'm attaching a screenshot comparing the login (testing with fake credentials).  Used Note++ with comparison plugin.  

Deleted: Headers 2017-08-03 09_59_51-_new 2 - Notepad++.png 132 KB

	Headers 2017-08-03 09_59_51-_new 2 - Notepad++.png 132 KB View Download

Here is the narrow bisect result:

https://chromium.googlesource.com/chromium/src/+log/50bbde70a79349d7c71655cb1042fa559fc4a568..99c274ae8e7d366261dcfb89e0b98e733fb9d5f4

Good#59.0.3071.115
Bad#60.0.3112.78

raphael.kubo.da.costa@, can you please look into this change (https://chromium.googlesource.com/chromium/src/+/99c274ae8e7d366261dcfb89e0b98e733fb9d5f4) ?

Thank you!

In M60, XHR.getAllResponseHeaders()' implementation was changed to return lowercased header names. This was done after the XHR spec itself was changed, and at this point both Chrome and the upcoming Safari 11 will follow the spec. Firefox did the same at one point, but reverted the change after some breakage was found during their testing.

Please take a look at the existing discussion in  bug 749086  as well as the one in the spec (https://github.com/whatwg/xhr/issues/146) and feel free to chime in as well.

Is it possible to get guidance on how we implement the workaround offered by Charles?  is it correct that the .js file is somehow installed on our Chrome client?  How is that done?

Full article from Cisco:
https://www.cisco.com/c/en/us/support/docs/security/email-security-appliance/211583-Cisco-ESA-WSA-SMA-Login-Workaround.html

Greasemonkey/Tapermonkey .js:
https://gist.github.com/robsherw/24c8d66634e260d00e363537eaa93460/raw/abd9eb3cf96bc87e92a6dbf03c71aa3dc22b1403/Cisco_ESA_SMA_XHR_fix.user.js

still the issue not resolved for Cisco WSA .Login is working fine but tamper monkey script appears immediately after login

Deleted: Untitled.png 58.3 KB

	Untitled.png 58.3 KB View Download

@jinujose - correct, the scripts only work properly on ESA and SMA; we do have a workaround that Cisco TAC can run from a remote session if opened to your WSA.  Please open a Cisco Support SR and have an available engineer assist.

For ESA, we have this fix implemented in our 11.0.0-272 (11.0 Hot Patch 2) release.

 Issue 796208  has been merged into this issue.