Update 7th Jan 2012: My original post assumed that the AddHeader() Method appended a second header to the response which caused the error- I've since realised that this is not the case, and it appears that ASP.NET (or more likely IIS) is clever enough to realise that there should not be multiple content-disposition headers and instead overwrites the generated header. The error in most cases is caused by a comma in place of a semi colon.
As a web developer I've always been a big fan of the auto updating features found in Chrome. But today I witnessed first hand the problems that auto updating can bring when a browser implements new security features.
Last week I began receiving odd error reports for a clients internal system for a feature that had been working for months and I hadn't made any changes to. When they tried to download resources from the database, they received the following error message:
Duplicate headers received from server
The response from the server contained duplicate headers. This problem is generally the result of a misconfigured website or proxy. Only the website or proxy administrator can fix this issue.
Error 349 (net::ERR_RESPONSE_HEADERS_MULTIPLE_CONTENT_DISPOSITION): Multiple Content-Disposition headers received. This is disallowed to protect against HTTP response-splitting attacks.
If you receive this error on someone elses website, contact the webmaster to make them aware of the problem. You can work around the issue by using another browser- I would recommend the latest version of Firefox.
It wasn't possible to examine the headers using the Chrome Developer Tools, but thankfully the error message was descriptive enough. On inspection of my code, I found the following line to be causing the problem:
Viewing the headers using Firefox's web developer tools showed that my original assumption of the header being defined twice was incorrect. Having read the W3C spec, I realised the error was not in how ASp.NET adds the header, but rather in how I had defined it using a comma instead of a semi colon. The problem line:
context.Response.AddHeader("Content-Disposition", "attachment, filename=""" + resource.FileName + """")
Clearly this just appends the new header to the response without removing or overwriting the one generated by ASP.NET. The fix seemed easy enough, I either needed to remove or edit the existing header.
The correct fix simply involves replacing the comma after 'attachment' with a semi colon, thereby making it a single header definition.
context.Response.AddHeader("Content-Disposition", "attachment; filename=""" + resource.FileName + """")
This is not a bug in Chrome, but rather a change of functionality where the parsing of headers is stricter.
The W3C spec allows multiple headers, but only in circumstances where they could be combined into a single header with a comma separated value value list.
Multiple message-header fields with the same field-name MAY be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list [i.e., #(values)]. It MUST be possible to combine the multiple header fields into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field-value to the first, each separated by a comma
Clearly with content-type this is not valid, a file can only have one content type.
On closer inspection of the spec, the Content-Disposition header is not in fact an official part of the W3C spec, but is simply documented because of its widespread use. Still, the format of headers and the use of commas to denote multiple values is standard, and this also affects other headers such as content-length.