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.
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.
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 Prizes.org (a Google property):
http://item.prizes.org/r/3/0000/i/EHrciSmPtz8g9NjjIBC32NsYpYkmIP24/
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?
Issue 105138 has been merged into this issue.
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!
Comment #29 on issue 103618 by kenji...@chromium.org: Error 349
(net::ERR_RESPONSE_HEADERS_MULTIPLE_CONTENT_DISPOSITION)
http://code.google.com/p/chromium/issues/detail?id=103618
I believe the issue is hitting Yomiuri (https://yorimo.yomiuri.co.jp/), 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.
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.
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.
ok.. Few instructions would take you to the page where I am having problem..
1. Go to https://www.formsite.com/app/FormSite?FormId=LoadLogin. Login with
username and password both as "demo".
2. Go to https://www.formsite.com/bld/FormSite?FormId=LoadResultsDownload,
select Data Delimiter as "Comma-Separated" or "Tab-Separated" and click on
Export and you should see Error 349
(net::ERR_RESPONSE_HEADERS_MULTIPLE_CONTENT_DISPOSITION):
Please let me know how I should fix this..
Thank you for help.
Well, you're sending the Content-Disposition header field twice. Don't, and
the problem will go away.
Can you pleas post the header values? or tell me how to see those? Thank
you for help
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.
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/steuererkl_rung_2011.spooler.download.1323783370950.exe/ptw10_new.exe">
Anybody knows, what the Problem with this link is? Works well in IE, but
not in Chrome.
thx for help
thx.. Julien.
So I can just put any problematic url into the form on redbot to let it
check, nice to know.
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.
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.
"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...
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.
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.
+1
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)!
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!
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
Thx
Richard, Firefox may not be reporting exactly what it got, or it's actually
getting a different response than Chrome.
Try with redbot.org 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.
Mike: did you send the WMS owners a bug report?
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.
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.