New issue
Advanced search Search tips

Issue 103618 link

Starred by 34 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Nov 2011
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

  • Only users with EditIssue permission may comment.

Sign in to add a comment


Reported by, Nov 9 2011

Issue description

Chrome Version       : 16.0.912.32
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: OK
  Firefox 4.x: OK
     IE 7/8/9: OK

What steps will reproduce the problem?
1. Download a file from a website that uses the content-disposition header to set the file name and said file name contains a comma (",").

What is the expected result?
A file will download

What happens instead?
The following error occurs...
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.912.32 Safari/535.7

I little more experimenting this morning has found a work around for my comma issue. 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. Keep in mind it worked correctly without the double quotes in previous versions of Chrome (and other browsers).

Comment 2 by, Nov 14 2011

Labels: -Area-Undefined Area-Internals Internals-Network-HTTP

Comment 3 Deleted

See test case at:

So this is an invalid header field, and Chrome has started to reject it with version 16. Seems like a good idea to me.
Status: WontFix
Marking as WontFix because it is working as intended. You should fix the header field in your server.
Will, I fear that this change will break many websites. Many services and servers do not enclose file names in quotes when sending a content header. This will cause those downloads to fail. See  issue 100011  for more users having problems.

If content-disposition is set as [attachment; filename=Doe, John.pdf] this will cause the error. Other users are having problems with tildes and other characters in the filenames. It is, of course, your call if you want to ignore this, but it will cause problems with many sites that have not enclosed the filename in quotes. More of backward compatibility issue, as I believe the original specs didn't specify the use of quotes (although I could be wrong, I'm not as versed in specs as browser developers)?

Thanks for looking in to this.
> More of backward compatibility issue, as I believe the original specs didn't specify the use of quotes (although I could be wrong, I'm not as versed in specs as browser developers)?

No. The specs have always been clear what the syntax is; so it's "only" an issue of backwards compatibility with previous versions (and other user agents).
 Issue 100011  has been merged into this issue.
It looks like there is only one more user in who has a problem. Considering Chrome 16 is on the beta channel, it looks like the fallout from our fix to be more spec compliant is pretty small. Unless there are many more instances, we're going to push this fix forward.
Thanks again, at least it is on your radar if issues do crop up when v16 goes mainstream.

To many examples out there do not include the quotes (attachment;, which is unfortunate for us web application developers because most file names these days contain spaces and other characters which would require them. To make matters worse, we never knew we were not confirming to spec because it just worked in all browsers. is your friend for checking HTTP response compliance...
Just wanted to note that I have also run into this issue.  I highly recommend that this issue be re-opened as it will break many web applications that have never tested this, including our commercial medical image viewer, which now no longer displays images in the new version of chrome, but it works in every other browser. Keeping Backwards compatibility is important to us for this issue. 
Labels: -OS-Windows OS-All Mstone-16
Thanks for the notice. If others see this, please chime in as well. I'm definitely open to reverting this if the fallout is big.

Comment 14 by Deleted ...@, Nov 16 2011

I have been having this issue all week.  Please fix~

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

Thanks for chiming in. Which URL do you see this on?

Comment 16 by, Nov 18 2011

Just got this error from a site. The headers (SSL, but inspected using Fiddler) were:

HTTP/1.1 200 OK
Connection: close
Date: Fri, 18 Nov 2011 11:40:09 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
cache-control: must-revalidate
content-disposition: attachment; filename=XXXXXXX_XXXXXXXXX_XXXXXXX from Thursday, December 09, 2010.csv
Content-Type: text/csv
Expires: Fri, 31 Dec 1999 23:00:00 GMT
Cache-control: private

So it looks like this could be solved with quotations around the filename.
This would have been much easier to debug if Chrome's developer tools showed me the headers, not the headers for the error page. D'uh!
I believe this issue also is affecting (a Google property):

I have also emailed the Prizes team with a link to this issue.
Interesting, it has:

Content-Disposition: inline; filename="MusicWidgetSmall.png"; modification-
        date: Wed, 16 Nov 2011 04:10:48 GMT

(the date should be a quoted-string)

Time to send a bug report?

Comment 19 by Deleted ...@, Nov 23 2011

The same problem appears if Content-Disposition filename param is encoded via RFC2231:

Content-Disposition: inline;

Comment 20 Deleted

Comment 21 Deleted

The example in comment 19 is invalid; it's missing a semicolon between filename*0* and filename*1.

Also, Chrome doesn't support continuations anyway; just put everything into a single parameter (see Finally, you really should look at RFC 5987, not RFC 2231.
 Issue 105138  has been merged into this issue.
I'm not sure why a comma would cause a problem since the field delimiter is a semi-colon, shouldn't a comma automatically be considered as part of the value?
The comma could be used by senders/libraries/intermediates to fold multiple header instances into a single one.

From RFC 2616:

   Many HTTP/1.1 header field values consist of words separated by LWS
   or special characters. These special characters MUST be in a quoted
   string to be used within a parameter value (as defined in section

       token          = 1*<any CHAR except CTLs or separators>
       separators     = "(" | ")" | "<" | ">" | "@"
                      | "," | ";" | ":" | "\" | <">
                      | "/" | "[" | "]" | "?" | "="
                      | "{" | "}" | SP | HT

Comment 27 by Deleted ...@, Dec 22 2011

I am experiencing the same error, as well as many other users (Error 349).  

Will Google fix this?  If so, when?

If not, how can I fix it?  I am responsible for uploading documents on a website, which users then download.  I have no experience in developing or designing websites.

Please advise as to the best approach.  Thanks in advance!
Basically, Chrome is becoming more strict in adhering to standards.   We expect other browsers to follow suit.  Receiving multiple content-disposition headers can actually be an indication of a hacking attempt.  There's no reason to suspect that's the problem in this case, but it's one of the reasons we're now disallowing it.

The problem you're running into is due to a bug in the webserver's code.  It's up to the server's administrators to fix it.
Labels: Hotlist-Japan
I believe the issue is hitting Yomiuri (, one the biggest newspaper in Japan:

Some of the thumbnails don't show up. Direct access to the URL shows the Error 349.

We should think about introducing an exception list like we do for SSL False Start and 1/n-1 record splitting: talking from experience with dealing with SSL False Start intolerance, what seems like an easy update to a server actually takes months. And in most cases, the website owners actually have no direct control on that...

I am happy to reach affected websites but I would need clear instructions on what they need to do and an exception list managed on a "gave ETA" basis to be effective.

So the problem is sending a filename in Content-Disposition containing a comma. 

This would work is the filename was quoted, or if the header field wasn't sent at all. (It appears to be ueeless here).

I agree that the error message is somewhat misleading (the header field isn't duplicated after all)-
Yea, I should update the descriptive text, or maybe differentiate between a single line with a comma and multiple lines, though not sure how complicated that would be, as we parse the headers and validate them in different functions.  Could actually allow them with commas - it's invalid HTTP, but it shouldn't be a security issue.

I'll try to get the error text updated for M18.  For anything more...  Well, we'll see.

Comment 32 by Deleted ...@, Dec 28 2011

I am getting the same error when I try to download CSV (Comma Separated file) but not when downloading Excel file.. 

I am downloading only single file . I tried to use " (quotes) around file name which does not have whitespaces in the file name. But it did not help. 
If the URL is publicly available, just post it and I'd be happy to take a look.  Otherwise, if it's HTTP rather than HTTPS, you could post a wireshark dump.  Unfortunately, chrome's internal logging of headers currently doesn't happen when header parsing fails.

Comment 34 Deleted

Well, you're sending the Content-Disposition header field twice. Don't, and the problem will go away.

Comment 36 Deleted

Comment 37 by Deleted ...@, Dec 29 2011

Can you please post the header values? or tell me how to see those? Thank you so much for help
On Windows, you can trace them with HTTP Fiddler. It shows that the header is indeed occurring twice.

Comment 39 by Deleted ...@, Dec 29 2011

Ok great..thank you for your help

Comment 40 by Deleted ...@, Jan 3 2012

I get the same Error, while visiting the website of the "Kantonale Steueramt" in Zurich Swiss. The Downloadlink appears to be
<a class="generic" href="/internet/finanzdirektion/ksta/de/steuererklaerung/software/_jcr_content/contentPar/downloadlist_0/downloaditems/">

Anybody knows, what the Problem with this link is? Works well in IE, but not in Chrome.

thx for help

Comment 42 by Deleted ...@, Jan 5 2012

thx.. Julien.
So I can just put any problematic url into the form on redbot to let it check, nice to know.

Comment 43 by Deleted ...@, Jan 25 2012

I am receiving reports that users of my web application are encountering this issue as well.  I am the developer of the application, and users are seeing this error when downloading files.  The download is initiated simply by performing a "window.location.href=<path to file>" from a form button. 

Comment 44 by, Jan 25 2012

esl810:  How you start the request isn't important.  You can get the error either be having two "content-disposition" headers in the response, or by having a content-disposition header with an unquoted comma, like:

content-disposition: attachment; filename=Hats, shiny.png

which should be:

content-disposition: attachment; filename="Hats, shiny.png"

"I am receiving reports that users of my web application are encountering this issue as well.  I am the developer of the application, and users are seeing this error when downloading files.  The download is initiated simply by performing a "window.location.href=<path to file>" from a form button."

Well. Check the response your server is sending (network monitor, redbot,org, whatnot...) and fix it.

Comment 46 by Deleted ...@, Jan 25 2012

Thanks... Actually, my server is not delivering the file.  All my application does is generate a URL to Akamai, which own responsibility for serving the file.  I'll have to see what it is that they are returning in their headers.
Let us know what you find because if the issue is indeed originating from Akamai that would be rather concerning.

Comment 48 by Deleted ...@, Jan 25 2012

Sigh... definitely getting multiple content-disposition headers back from Akamai:

HTTP/1.1 200 OK
Server: Apache
Accept-Ranges: bytes
Content-Type: application/zip
Content-Disposition: attachment
Content-Disposition: attachment
Content-Disposition: attachment
Last-Modified: Mon, 15 Aug 2011 19:25:54 GMT
ETag: "1ea0c637597af3e3daa089bbb0012484:1314720711"
Content-Disposition: attachment
Content-Length: 130859369
Date: Wed, 25 Jan 2012 17:47:31 GMT
Connection: keep-alive
Content-Disposition: attachment

Comment 49 by Deleted ...@, Feb 10 2012

I get these when the intranet site I built for people to download a dynamic csv file.  this is literally the first time Chrome has ever fallen short, and IE renders perfectly.  Google PLEASE do not allow this to happen ever again or I will lose faith in humanity. 
-code Monkey
"I get these when the intranet site I built for people to download a dynamic csv file."

If it's a site you built yourself then it should be straightforward to fix it...
Hey guys and gals,

I realize that this issue is listed as closed/won't fix and has been for some time.

I wanted to report that I have a legacy ASP application (over whose source code I don't have control) which returns  content-disposition headers that look like:


The filename parameter is not configurable in our case: it's based on other data. This is causing error #329 for many of our users, and some serious pain for us. It has been recommended to me that we should note to our users that they should not use Chrome to browse the application in question.

While I'm inclined to do some apache configuration fiddling instead to rewrite this header, it should be noted that this rather unusually serious and irritatingly fatal error message, while a design choice, may affect browser adoption. Certainly, this is a very peculiar use case, but I think the positives for security on this decision are outweighed by the negatives for usability. 

I might consider reworking this as an option that users might toggle, which defaults to off. This strikes me a bit as having <b> (or some other deprecated tag) raise a fatal error when a user browses a page that contains it: I imagine that there are many well-intentioned legacy sites out there that don't have perfectly configured headers, despite the fact that they are not in the spec.

I have also gotten this error on numerous sites that I use. Most are educational sites. This has been going on for quite some time. I have just gone back over to Firefox to get the files I need. It would be nice to be able to just do what I need to in Chrome.

Comment 53 by Deleted ...@, Feb 15 2012

Just to close the loop... Akamai had to implement a custom solution just for serving my (company's) content to remove the extra Content-Disposition headers (see comment 48 above).  Initially they thought that they would have to do this for every individual URL that is served, so it does not appear that they can implement a global solution for all of their customers' files.  Given the amount of content served by Akamai, you might want to reconsider handling this issue at the browser level, or working with Akamai to understand why they aren't conforming to strict standards, as it might ultimately end up costing you end users.
Thanks for the comments guys. We'll try to reach out to Akamai. And we understand the web compatibility cost. Sometimes we have to break some sites in order to move the web forward. This has been in long enough that it's unlikely we'll revert it (we think the compatibility cost is small enough). I advise web devs to fix the content. At some point, other browser vendors will follow, so at some point the no modern browser will support these broken sites. Sorry for the hassle.

Comment 55 by, Feb 18 2012

FYI, this change has broken downloads from Desire2Learn (D2L), which is used by hundreds of thousands of students and faculty at major colleges and universities across the country (and probably internationally as well). I'm not sure if it's on the radar to be fixed by D2L but in the meantime this change is forcing a LOT of students and faculty to use other browsers. Standards compliant or not, the effect is the same: aggressively driving users away from Chrome.

Remember that from the end user's perspective, this is a Chrome issue, not a web dev issue. The people who will field the complaints at the universities have their hands tied just as much as the students, and even if/when D2L addresses the issue, getting approval for the upgrade could take weeks or months in a university bureaucracy. In the meantime you will have hundreds of thousands of users being necessarily driven to other browsers just to do something as simple as download a syllabus (or much more critically, an assignment that has been turned in and corrected with feedback, which is how I ended up making this comment here as a faculty member fielding student complaints). Some filenames can be changed; others cannot as they are system-generated.

I understand the desire to drive things forward, but you should balance this with an equal desire to not run over your users in the process. I'm not suggesting you should permanently "break" (revert) this change, but perhaps an interim solution such as warning the user but allowing the download would be a good compromise until everyone catches up. In the meantime, I have no choice but to tell students to use another browser, and I don't have the time or inclination to explain your well-intentioned rationale.  The bottom line is that Chrome doesn't work for us (and hundreds of thousands of others) as-is, regardless of who's at fault.
I think what people are telling you is that it isn't just a hassle, it means that many sites will just drop support for chrome. I may do so, and have no problem explaining to some of the largest medical corporations in the world that chrome is too unstable to support. Firefox has chosen to go the corporate support route, not the "I don't care what you think, I'm going to just disable your site because I'm too big to fail" mentality.
FWIW, I also ran into this issue when trying to download legal documents from a third party web site. It's not realistic to expect users to contact random web developers and explain this issue to them in the hope of getting access to downloadable files, see for example the confusion in .

In the spirit of putting the user first, would you consider turning this into a warning instead of a fatal error? I think it's unfortunate to force people to use a different browser for this purpose.

Comment 58 by, Feb 22 2012

Experiencing this some company intranet sites (E.g. Lotus Connections, which is our primary infrastructure for sharing documents).

No interest to fix the problem server-side: It works for IE, which is the official browser for the company.

I care too much about security to go down that route.  Please fix (un-fix because it's not spec-compliant)!

Comment 59 by, Feb 22 2012

So that is the final word on it then?

1. Chrome won't fix (un-fix) this.
2. Chrome won't give me a knob for compatibility with older server implementations.
3. Nobody sees a reason to fix this server-side within a reasonable time-frame: It works with IE (Even with IE9 which uses compatibility mode for intranet infrastructure).
4. I (and many others) are stuck with a browser that doesn't support a critical part of my daily workflow: Downloading documents.

Thank you Chrome team for showing me the error in my ways!  I'll be promoting IE and Firefox from now on!

Comment 60 by Deleted ...@, Feb 23 2012

Please remove me from this thread. did you star the issue? if so, unstar it and you should stop receiving updates.

Comment 62 by Deleted ...@, Feb 27 2012

I also have the net::ERR_RESPONSE_HEADERS_MULTIPLE_CONTENT_DISPOSITION issue, but i don't send content-disposition twice, i use smi-colon separator and i don't have comma in the name.
Here is the http response header get backed from Firefox :

HTTP/1.1 200 OK
Date: Mon, 27 Feb 2012 09:48:32 GMT
Server: Apache/2.2.14 (Debian)
X-Powered-By: PHP/5.3.3-7+squeeze3
Content-Transfer-Encoding: binary, binary
Content-Length: 637470
Content-Disposition: attachment; filename="BI_3701_2004B00059_2009_7563.pdf"
Expires: 0, 0
Cache-Control: no-cache, must-revalidate, no-cache, must-revalidate
Pragma: no-cache, no-cache
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: application/pdf

I don't understand what is the problem. If i need to modify my server code, i will, but i need to know what's wrong

Richard, Firefox may not be reporting exactly what it got, or it's actually getting a different response than Chrome.

Try with or a proper HTTP trace tool.

Finally: there is no Content-Transfer-Encoding header field in HTTP. Also: you have repeating values in Content-Transfer-Encoding, Cache-Control and Pragma. So this definitively looks fishy.

Comment 64 by, Feb 28 2012

I am getting the same issue here. Also recommending people to use a better browser. I love it that you guys make a change and its "moving the web forward". Ridiculous.

Comment 65 by Deleted ...@, Mar 13 2012

I can't download my ebooks in epub from
They sent me here to fix the problem I have Google Chrome, and I'm thinking about hitting the delete as my fix. I don't understand a word of what you're talking about.

Can anyone tell me in simple terms what I need to do to avoid getting the nasty-grams instead of my ebook? 

Comment 66 by, Mar 13 2012

Simplest possible terms: USE A DIFFERENT BROWSER. The recent change in Chrome breaks downloads from many sites and they have said they don't intend to fix it. That's all you need to know.

Comment 67 by Deleted ...@, Mar 13 2012

I'm having the same problem when accessing GIS information from some third-party servers. Their WMS (Web Map Service) servers are not enclosing the Content-Disposition in double quotes, and commas pertaining to Lat / Long coordinates are triggering this error in Chrome. 

I am able to successfully access the same information through IE, Firefox, & Safari.

This is a very frustrating for Chrome users & developers who have no control over the content causing this issue.
Mike: did you send the WMS owners a bug report?

Comment 71 by, Mar 21 2012

Very glad to see that, if I understand the last message correctly, this is being addressed despite the WontFix status.  I'm particularly glad because I encountered the issue again this morning trying to retrieve an attachment from my personal email via the web interface.  I use Apple's iCloud service and a comma in the attachment name prevented it from being downloaded via Chrome.  If a giant like Apple is "broken" then I don't think it's reasonable to continue saying you're not going to address this.

So ... assuming I understood that correctly, thank you!
> ...If a giant like Apple is "broken" ...

It is, so is Safari. But so is also GMail, and Microsoft Exchange. File bugs. Complain. Blog about it.

That CL won't actually fix the comma issue, just the issue with servers that send 5 dozen copies of the same Content-disposition line.  Have another on the way that will be a bit more permissive with commas, though may still be a little more strict than other browsers.

While these problems are ultimately due to broken servers, there are a number of reasons so many servers are broken in the first place - overly permissive browsers that allow them to get away with it in the first place, an overly complicated spec, and bad protocol design decisions made over a decade ago.
Julian - I did send a bug report to the owners of the WMS server. Glad to see some developments on this as well.

Comment 75 by Deleted ...@, Mar 22 2012

I have come across this issue today. I am part of the IT Support team at UniSA and we use echo360 as a lecture recording tool and it looks like it is not conforming with HTTP header standard and giving the error in chrome. Would be helpful if there was an option in chrome for switching to low compliance mode or something similar which would ignore some of the errors. We are escalating this with our external supplier but all changes take time.

Comment 76 by Deleted ...@, Mar 25 2012

I am confused are the links posted by on march 21st the fix for this problem? and if so, how do I use them.

Comment 77 by Deleted ...@, Apr 4 2012

not fixed in version 18.  Is there a way for us to force this or has the fix not been committed yet?  if this isn't allowed to be reduced then i'll switch my clients back to IE post is good due to direct GPO support but to if it breaks their critical cloud app.
I implemented my application downloading PDF file and had problem with

Content-Disposition: inline, filename="export2.pdf"

when corrected to

Content-Disposition: inline; filename="export2.pdf"

it works, maybe it helps someone ;-)

Comment 79 by, Apr 9 2012

I just had this issue - I used IE to download the file...

Comment 80 by, Apr 23 2012

I understand: The spec and chrome are correct.
Problem is: If servers around the world use incorrect header-format and are ignorant to that problem, it might be more of a google-problem.

I know that is stated earlier in this ticket, but I feel the need to say:
PLEASE, ignore the spec, just warn or something, but get it running just as it did before and in all other browsers.

Comment 83 by Deleted ...@, May 3 2012

I, too, am getting the error message when trying to d/load pdf docs which, as other have stated, is done multiple times daily.  Unless, or until, Google fixes this, Chrome is no longer a viable option for me, my company, or our clients & accounts.  Despite all the other good points, we're moving, en masse, back to Firefox.

Comment 84 by Deleted ...@, May 9 2012

I browse Apple's iTunes connect web site to download promotion code file for my account and I get this message. Can't give you a URL since it's inside my account at iTunes connect. I don't have an option to convince Apple to fix their web site, and your change makes it impossible for me to use the web. Please fix.
Denis, I have forwarded your comment to two Apple employees. Maybe it finds its way to the right team.

Comment 86 Deleted

Comment 87 by, May 15 2012

Same issue here guys when trying to access the following

chrome version: 18.0.1025.168

Comment 88 by Deleted ...@, Jul 26 2012

My problem has to do with handling of colons in sitename or ip addresses. Many websites use ports declared with the type address. With IE this refers without problems. Not sure about other browsers. Chrome throws a wobbly and gives us a %3A conversion which is of course, not a valid address. Not good Chrome. Not good. Follow common practice, not obstinacy.
redrider:  What does that have to do with getting the "ERR_RESPONSE_HEADERS_MULTIPLE_CONTENT_DISPOSITION" error?  If it's a different issue, you should file a different bug.
See <>

These header field values are broken, and guess what, Firefox rejects them as well: "The page you are trying to view cannot be shown because an error in the data transmission was detected."
Project Member

Comment 93 by, Oct 14 2012

Labels: Restrict-AddIssueComment-Commit
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 94 by, Mar 10 2013

Labels: -Area-Internals -Internals-Network-HTTP -Mstone-16 Cr-Internals-Network-HTTP Cr-Internals M-16
Project Member

Comment 95 by, Mar 13 2013

Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Components: Internals>Network
Components: -Internals>Network>HTTP

Sign in to add a comment