New issue
Advanced search Search tips

Issue 100011 link

Starred by 7 users

Issue metadata

Status: Duplicate
Merged: issue 103618
Owner: ----
Closed: Nov 2011
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug

  • Only users with Commit permission may comment.

Sign in to add a comment

Multiple Content-Disposition headers received

Reported by, Oct 12 2011

Issue description

Chrome Version       : 16.0.904.0
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Safari 5:
Firefox 4.x:
     IE 7/8/9: OK

What steps will reproduce the problem?
1. go to

What is the expected result?
an image

What happens instead?
Error 349 (net::ERR_RESPONSE_HEADERS_MULTIPLE_CONTENT_DISPOSITION): Multiple Content-Disposition headers received. This is disallowed to protect against HTTP response splitting attacks.

Please provide any additional information below. Attach a screenshot if

UserAgentString: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.904.0 Safari/535.7

I can confirm this happens when setting content-disposition on the newest version of Chrome. It only appears to occur if the filename property contains a comma (ie, the file name has a comma "," in it.)

Comment 2 by, Nov 10 2011

But... there is no comma in 
I just noticed this on our platform that only certain files would not download (all using the same program to pull and render to the browser) and it was the ones with commas in them. Your example seems to be caused by a different issue. My guess is that has something to do with the resulting file name, as other images seem to work (example:
If the image name is not important and you control the site, I would suggest changing the program to render the file name as fileid.jpg. For example 8690.jpg. My guess is this will fix your problem until Chrome is patched.
I little more experimenting this morning has found a work around for my comma issue, and may apply to you. When setting the content-disposition, make sure the filename parameter is surrounded by double quotes...

This fixed the problem for me in Chrome. Oddly enough, almost all examples I googled on the web do not mention the double quotes requirement. Also, it is unclear if the filename parameter should be followed by a semicolon, but it doesn't seem to matter.

Comment 5 by, Nov 10 2011

I see you wrote 'My guess is this will fix your problem until Chrome is patched.'.

So it's Chrome here who's not playing by the book? or is it our CMS?

I believe this a problem where Chrome is being more strict than other browser in regards to the content-disposition header. I would consider it a Chrome bug, as it will break a good many websites.
That said, if you send my response to the developers of your CMS, then they should be able to work around it (as I did) pretty quickly by enclosing the filename in double quotes in their content-disposition header (assuming the root cause is the same as mine).

Comment 7 by, Nov 14 2011

Thanks for the assistance! I've taken it up with the developers, and the double-quotes take care of the problem.  :-)
Please note that using quotes will fix issues with delimiters such as "," or whitespace, more work will be needed to make non-ASCII characters work. See
Mergedinto: 103618
Status: Duplicate

Comment 10 by, Dec 15 2011

I can duplicate this as well.  duplicate Content-Disposition with the exact same content will cause an error in our software as well.

Comment 11 by, Dec 15 2011

I can duplicate this as well.  duplicate Content-Disposition with the exact same content will cause an error in our software as well.
38.4 KB View Download
If it's your software (sending the duplicate headers), you may want to fix it.

Comment 13 by, Dec 15 2011

Thank you captain obvious, I would like to point out, this doesn't happen in IE, Opera, or Firefox.  Chromium is the only browser this happens in.
You're welcome.

If you head over to  Issue 103618  (the issue this issue was merged in) you'll see that yes, this is intended, and no, that you can reproduce this isn't really a surprise. It's by design.

And yes, if Chrome manages to keep this change in the release, at least one additional browser may follow.
Just got bit by this, but in my case it was because I had:


instead of 


(comma instead of semicolon before filename). So not just commas in filenames will cause this.

Comment 16 by Deleted ...@, Feb 17 2012

Hi I happen to be doing everything right, I guess, but I am still getting this error in the latest version.... here is my code.

response.AppendHeader("Content-Disposition","attachment; " +"filename=\"" + filename + "\"; " +"size=" + downloadBytes.Length.ToString() + "; " + "creation-date=" + DateTime.Now.ToString("R") + "; " + "modification-date=" + DateTime.Now.ToString("R") + "; " + "read-date=" + DateTime.Now.ToString("R"));

Is anything wrong with the code above? Any help will be greatly appreciated.

Drop all parameters except "filename". Also, if filename contains non-ASCII characters, encode it as defined in RFC 5987.

Finally, you can test your server's response with
Project Member

Comment 18 by, Oct 13 2012

Labels: Restrict-AddIssueComment-Commit
Mergedinto: chromium:103618
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 19 by, Mar 11 2013

Labels: -Area-Undefined

Sign in to add a comment