Google Chrome Reports “Duplicate headers received from server”

It seems that this error message has been around since version 16 of Chrome, and was first reported sometime in 2011.

The error message basically says that it received two Content-Disposition headers, and that the response was blocked to prevent HTTP response splitting attacks.

However, in most cases this error isn’t caused by malicious code, but rather because of an innocuous comma in the filename parameter of the Content-Disposition header. Here’s an example of an actual response header I received while downloading a resume from a popular career site:

Content-Disposition: attachment; filename=Beresky_Resume,6pg.docx

That was the only Content-Disposition header in the entire response, which raises the question: Why is this a duplicate header?

Because according to the HTTP 1.1 specification, section 4.2 Message Headers:

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.

Hence, Chrome is correctly interpreting the Content-Disposition header as two Content-Disposition headers, one with the value attachment; filename=Beresky_Resume and the other with the value 6pg.docx

I don’t know that this error message should bother referencing HTTP response splitting attacks, as in most cases that’s going to be a red herring. The real problems are that:

• Two Content-Disposition headers are not valid in this HTTP response. There is only one body, one binary file, and hence it can only have one disposition.
• The “second” header (as interpreted by the browser) has the invalid, or at least useless, value of 6pg.docx
• The filename parameter should support the least-capable file system, and not all file systems (and/or file sharing protocols) support commas in file names.

The solution is to make a change at the server to encode commas, replace them with another character, or omit them entirely when passing a filename parameter in the Content-Disposition header.

In the meantime, if you need to download a file containing a comma but have no control over the server, it appears that IE, FF, and Safari are all far more permissive and will download the file appropriately.

END.

Don’t mind me, I’m just putting the full error text below so that this article can be found more easily when searching. (I hope it was helpful enough to warrant such treatment!)

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 distinct Content-Disposition headers received. This is disallowed to protect against HTTP response splitting attacks.