New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
This site will be read-only for 3-4 hours starting at Sunday, 08:00AM PDT
Starred by 68 users

Issue metadata

Status: Fixed
Closed: Jul 2013
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

issue 68356

  • Only users with EditIssue permission may comment.

Sign in to add a comment

Can't download a .pdf file served as binary/octet-stream

Reported by, Nov 15 2011 Back to list

Issue description

Chrome Version       : 15.0.874.120
OS Version: OS X 10.6.8
URLs (if applicable) : N/A
Other browsers tested:
     Safari 5: OK
  Firefox 6.x: OK
     IE 7/8/9: Not available for me

What steps will reproduce the problem?

1. Serve a file somewhere using the header Content-Type: binary/octet-stream, e.g. (I will leave this up for a few days only)
2. Click on a link pointing to that file

What is the expected result?

- The file should download.

What happens instead?

The download is cancelled before it completes and is shown as Status: (canceled) in the inspector and the file does not download, or sometimes partially downloads.

Attached is a screenshot of the inspector.

- Files uploaded to Amazon S3 by default get this content type, unless you upload via the web console. 
- Older versions of Chrome (not sure how old) used to work fine with this.
- I've tested on two different computers and saw the same problem.
- I know the official way to download files is with a Content-Disposition header, but it wasn't necessary in the past and other browsers seem happy without this.

UserAgentString: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.874.120 Safari/535.2

Screen shot 2011-11-15 at 17.18.52.png
24.0 KB View Download
Labels: -Area-Undefined Area-UI Feature-Downloads Feature-DevTools
The "canceled" description is likely because the download is being handled by Chrome's download manager rather than WebKit.

If Chrome's download manager isn't handling the file correctly, then that's a different problem. If you can reproduce this, can you provide a net-internals dump using the instructions here:

I was unable to reproduce the problem on my own machine.

DevTools folks: Should there be a clearer message for downloads being handled by Chrome's download manager?  
Status: As

Comment 3 by, Nov 22 2011

Status: Assigned

Comment 4 by Deleted ...@, Nov 25 2011

Same problem on windows version...
it won't force download using this content-type.

I tried application/octet-stream, binary/octet-stream,  application/force-download and have same results.

Can you check that ?

Thank you.

Comment 5 by Deleted ...@, Nov 25 2011

@1 Here's a net-internals dump of the event. Hope I've done it correctly.
90.3 KB View Download

Comment 6 by, Dec 14 2011


Comment 7 by Deleted ...@, Dec 18 2011

I'm getting something similar when attempting to download a JAR (Java archive) file from Amazon S3 (I only mention this because the OP was from S3 too). If I enable the network tab I see any attempt to download go to (canceled). The actual download returns a HTTP 200. No file ends up in Downloads/.

I'va also seen occasional attempts by Chrome to download ranges of the file. Typically Chrome will ask for just one byte, and S3 returns a 206 (partial?) with the one byte. A bit bizarre...

The content-type for this file is application/java-archive

I wrote about it here:

Comment 8 by Deleted ...@, Dec 20 2011

I have the same issues with Chrome 16 and downloading files with content type binary/octet-stream.

Does onayone managed to solve this?

Comment 9 by, Dec 20 2011

I can confirm this issue on Chrome 16.0.912.63 with a mime-type of binary/octet-stream. I tried to click on a link that went to a PNG hosted on Amazon S3, and there was no action upon clicking the link. Right-clicking and choosing 'open in new tab' opened a tab with about:blank as the location.

However, right clicking and 'saving link as' resulted in a completed download.
Same problem here, however I don't know how to tell whether the issue is with Chrome or WebKit.  I've attached the net-internals dump to download (note that this is an access controlled file, so this link won't work.)  Clicking the download link opens a new tab, but does not download the file.
385 KB View Download
Oh - this is using 15.0.874.15 dev on OS X 10.6.8
Same problem here -  trying to access PDFs on S3 that have "binary/octet-stream" content types.

Chrome 16.0.912.63 m on Windows 7
Labels: -Feature-DevTools
Owner: ----
Status: Available
This bug encompasses two separate issues, one downloads related and one devtool related.  I've created  issue 109288  to handle the devtool issue, and put vsevik as the owner.  I don't think he makes sense as the owner of the download related version.  
 Issue 109172  may be a dup of this one.

Comment 15 by Deleted ...@, Jan 9 2012

We have the same issue on Windows XP and Windows 7.
Same problems here on Chrome 16.0.912.75 m and Windows XP

 Issue 109172  has been merged into this issue.
 Issue 109391  has been merged into this issue.
Labels: Mstone-19
Blocking: 68356
One additional note that may help: It seems I can download files if I ctrl-click the link and choose "save link as..."
windows 17.0.963.38 beta-m
can confirm it as well - seems from the headers to me that chrome asks for a partial download with zero range: same start & end point

I got the same problem, please fix it soon. 

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

Same problem. Linux 17.0.963.38 beta
Same problem here windows 7 64, Chrome 16.0.912.77 m. Seems to be a problem with pdf's.
Status: Assigned
Asanka: You indicated you could take a look at this?

Comment 27 by Deleted ...@, Jan 31 2012

Same problem here, windows 7 64, Chrome 16.0.912.77.
The problem appears to be:

* We have a request URL that looks like "path/to/file.pdf" and a MIME type of "binary/octet-stream". We don't do content sniffing for "binary/octet-stream".  We do limited sniffing for "application/octet-stream" but it won't help in this case.

* In BufferedResourceHandler::ShouldDownload() we check if there are any plugins that can handle our request by calling PluginServiceImpl::GetPluginInfo().

* GetPluginInfo() calls PluginList::GetPluginInfoArray() which adds plugins that support the MIME type and the extension (as determined by the URL). In our case, we add no plugins based on the MIME type, but we do add the PDF plugin based on the "pdf" extension in the URL.

* Since we have a plugin, the request is not handled as a download, and is handled by the renderer.

* The request proceeds, and the renderer receives ResourceMsg_ReceivedResponse.

* Deep in WebKit-land, we call FrameLoaderClientImpl::dispatchDecidePolicyForResponse() to determine what needs to be done with this response. This calls FrameLoaderClientImpl::canShowMIMEType("binary/octet-stream") to see if the renderer or a plugin can display the contents.

* Since the MIME-type can't be displayed, the renderer cancels the request.

In short, the browser and the renderer appear to disagree on who should handle the request, and we drop it on the floor.

Perhaps one solution would be to use the |actual_mime_type| as determined by PluginServiceImpl::GetPluginInfo() as the MIME-type for the request in BufferedResourceHandler.

Does this seem sane/reasonable?

Just to confirm - I found this problem with files of other types (e.g. JPG), not just PDF.
Someone in my team tried to add an (additional) Content-Disposition : "Attachment" header, and found out that this forces Chrome to download. Looking at the code for  BufferedResourceHandler::ShouldDownload() it's obvious why:

bool BufferedResourceHandler::ShouldDownload(bool* need_plugin_list) {
  if (need_plugin_list)
    *need_plugin_list = false;
  std::string type = StringToLowerASCII(response_->mime_type);

  // First, examine Content-Disposition.
  std::string disposition;
  request_->GetResponseHeaderByName("content-disposition", &disposition);
  if (!disposition.empty()) {
    net::HttpContentDisposition parsed_disposition(disposition, std::string());
    if (parsed_disposition.is_attachment())
      return true;
#30: That's how the Content-Disposition header is supposed to work.

This issue is specifically about the behavior of Chrome when no Content-Disposition is present and the Content-Type is incorrect.

Labels: -OS-Mac OS-All
The behavior on ToT is slightly different from #28. Specifically, a plug-in is added by URL derived extension only if PluginList::AllowMimeTypeMismatch(plugin_mime_type, response_mime_type) is true.

But the general issue is still there. E.g.: For a response like:

  Content-Type: application/octet-stream

  BufferedResourceHandler::ShouldDownload() returns false.
  FrameLoaderClientImpl::dispatchDecidePolicyForResponse() yields a PolicyAction of PolicyIgnore.

  => The request isn't handled by downloads or WebKit.

Adding abarth and jam for expertise on plugin-WebKit interaction. Do you think we should try to fix ShouldDownload() logic to match the logic in FrameLoaderClientImpl::dispatchDecidePolicyForResponse()? Or pursue something which doesn't involve keeping these two functions in sync?

In the current design, those two functions need to be kept in sync, which is kind of lame.

Comment 34 by, Mar 27 2012

Labels: -Mstone-19 Mstone-20 MovedFrom-19
Summary: Can't download a .pdf file served as binary/octet-stream (was: NULL)
 Issue 121125  has been merged into this issue.

Comment 37 by, Apr 24 2012

 Issue 124775  has been merged into this issue.

Comment 38 by, Apr 24 2012

Labels: -Area-UI Area-Internals Internals-Network

Comment 39 by Deleted ...@, Apr 24 2012

This same issue appears to be happening for me with a PHP-generated CSV file, but only if I use Content-Disposition: attachment; if I leave that off, the file opens correctly in a new tab, but I want it to download.  I have tried Content-types text/csv, Document, and application/force-download, all with no effect: the download is cancelled even though the header status is 200 in the Network tab.  I've had other people in my office try, and both a Windows 7 and Mac user were able to download the file with no problems.

Chrome version: 18.0.1025.162 m
"application/force-download" isn't the right way to force a download.  The proper way is to use:

Content-Disposition: attachment; filename=foo.pdf

I have the same problem with version 18.0.1025.168 on Linux when downloading PDFs from a SVN-HTTP respository. The content type there seems to be: "application/octet-stream" and Apache(2.2) or mod_dav_svn logs:
Unable to deliver content.  [500, #0]
(104)Connection reset by peer: Could not write data to filter.  [500, #0]
Labels: -Mstone-20 Mstone-21 MovedFrom-20
M20 has sailed. If this need to be part of M20, please put them back with release blocker label.
Labels: -Mstone-21 Mstone-22
Blocking: chromium:68356
 Issue 132580  has been merged into this issue.
@balrogthane: That doesn't sound like this problem; at least, if you don't have a plugin registered for .csv files, it's not this problem.  Could you visit "about:plugins" in your browser, scan for .csv, and if .csv isn't anywhere on that page, file a new bug?

asanka: Is this still an issue where Chrome and WebKit diverge on download policy for particular content types?

I understand that you'd like to reuse the same function here to ensure that these stay in sync, but I am wondering if there is a short-term fix for certain content types.

If not, let's move from M22.
Labels: -Mstone-22 Mstone-23
Moved to M23.

The issue is still there. The Chrome side policy decision takes a few more factors into account than the WebKit side policy decision. E.g. the Chrome side decision takes the result of PluginServiceFilter into account, which WebKit does not.

 Issue 133107  has been merged into this issue.
I spent some time investigating this.  One solution would be to have WebKit notify the browser process when it's unable to render for lack of MIME type support.  This could be done by sending an IPC message from RenderViewImpl::didFailResourceLoad...however by this time WebKit has already sent a ResourceHostMsg_CancelRequest message.  If you take a look at WebCore::ResourceLoader::cancel(const ResourceError& error) you can see how |error| is only passed to didFailToLoad (which calls RenderViewImpl::didFailResourceLoad) *after* m_handle->cancel() is called.  Asanka also noted that didFailToLoad is not always called after m_handle->cancel() so the browser process cannot wait for the message from didFailToLoad assuming [wrongly] that it always arrives after the cancel message.  It would be most convenient if, in the browser process, we knew before canceling a resource request that it wouldn't be rendered and instead we should just download the resource.
Paul is looking into this.
Labels: -Mstone-23 Mstone-24
 Issue 156375  has been merged into this issue.
Handing back to asanka@ who has a CL that after discussion with rdsmith@ seems like the appropriate short-term solution to this issue.  Long-term we'd like to catch the cases where neither the browser nor WebKit handles a file and instead download it.
Labels: -Mstone-24
Since the bug has moved few times, removing the milestone label. Please target the right milestone.
My csv export isn't getting prompted to save/download, it's rendered on the screen. 

bsamayoa: See  issue 152911 
I've seen that same problem downloading an xls file with an <a href> and this response headers:
Content-Disposition:attachment; filename="foo.xls"
Date:Thu, 29 Nov 2012 08:23:24 GMT
Expires:Thu, 19 Nov 1981 08:52:00 GMT
Keep-Alive:timeout=5, max=98
Server:Apache/2.2.22 (Debian)

I workarounded it by adding a target to it, if it helps someone ;-)
@me: Just confirming that the behavior you're seeing is that when you click on the .xls file link nothing happens (i.e. you don't see a download and you don't see it displayed in the browser)?  That surprises me, as AFAIK we don't have a plugin that displays excel spreadsheets, which is what's producing the problem for .pdf.

Comment 61 by, Nov 29 2012

Plugins are N/A to the issue as far as I've seen. One of the previous reports merged into this one:

I really can't believe this issue is still around.
Owner: ----
Status: Available
I'm not going to be able to get to this anytime soon.

Comment 63 by, Nov 29 2012

Yeah, it's been over a year, I just tell people to use a different browser.
Status: Untriaged
Switching to Untriaged to get into the next triage round.

Comment 65 by, Dec 17 2012

Labels: -Internals-Network
Taking internals-network off so download folks only get this.

Comment 66 by Deleted ...@, Jan 1 2013

uh... any movement on this? 
Labels: Mstone-26
Status: Assigned
I'd like to see this happen in MS-26.  
Not only does chrome cancel the request, it displays any requests made to the same server at the same time as cancelled.
chrome bug.PNG
12.1 KB View Download
Labels: -Mstone-26 Mstone-27

Comment 70 by Deleted ...@, Mar 3 2013

Seriously, this is beyond a joke now. This issue has been hanging around for over a year now.

It is happening to me on exe files. The latest one is even on a Google Site. (see attachment)

System Details

OS: Windows 7 Professional SP1
Chrome: Version 25.0.1364.97 m

Surely there must be a fix for this by now. It is a little infuriating.
chrome error.png
160 KB View Download
Project Member

Comment 71 by, Mar 10 2013

Labels: -Area-Internals -Feature-Downloads -Mstone-27 Cr-Internals M-27 Cr-UI-Browser-Downloads

Comment 72 by, Mar 15 2013

Same here, im having an error generated when downloading reports in CSV, TXT, and XLS/XLSX format.

Im using the following headers(Kohana 3.0.8):
$this->request->headers['Content-type'] = 'application/vnd.openxmlformats-officedocument.spreadsheetml.sheet';

$this->request->headers['Content-disposition'] = 'attachment; filename="'.$report_name.'.xlsx"'; 

Chrome cancels the download, sometimes the files download, sometimes they dont. Its frustrating since it gives a sense of instability to the feature when programmatically the files are being generated and sent as they should.

error in console:

Resource interpreted as Document but transferred with MIME type application/csv.

chrome bug.tiff
56.8 KB Download

Comment 73 by, Mar 21 2013

I'm also noticing a problem when setting content-disposition to attachment with a number of content-types. 'text/csv' seems to be working ok, but 'text/plain' and 'application/octet-stream' always fail to download, and 'text/tab-separated-values' seems to fail intermittently. 
Is there a combination of headers that reliably works around this problem, preferably without breaking download behavior in other browsers?

I see a couple of solutions upthread for very specific circumstances, but no "here's what to do to get plain ol' application/octet-stream downloads to work 100% of the time".  Apologies if it's there and I've overlooked it.

Comment 75 Deleted

Comment 76 by Deleted ...@, Apr 15 2013

I'v found a fix, workaround to force download with the attribute "download".
Try <a href="teste.pdf" download="teste.pdf"></a>
Tested on version: 26.0.1410.64 m

Helpful if you've got an <a> tag; thanks for the solution.  I'd rather fix (well, by "fix" I mean "modify to cater to Chrome") the response headers so the download works even when the request isn't initiated by an <a> tag, though.
#77: Content-Disposition: attachment; filename=foo.pdf

Comment 79 by, Apr 15 2013

Labels: -M-27 MovedFrom-27 M-28
 Issue 233927  has been merged into this issue.

Comment 82 by Deleted ...@, May 7 2013

I meet with same issue when download excel in my site. Anyone have the solution for chrome now?
Project Member

Comment 83 by, May 8 2013

Labels: -M-28 MovedFrom-28
This issue has already been moved once and is lower than Priority 1,therefore removing mstone.
I am seeing a similar issue for a regular, correctly-mime-typed (video/mp4) download from Google Cloud Storage on Mobile Chrome for Android. It switches to the player view and then fails to play. Is this separate because it's not the download manager, or the same because the download manager is intercepting it and letting it fall on the floor?

I'm having difficulty figuring out how to attach a network trace from Mobile Chrome to corroborate.
#84: If the MIME type wasn't application/octet-stream, then you aren't seeing this issue.

Seeing the same issue
AddType application/octet-stream .pdf .mp3 .zip in the .htaccess

Chrome will not download any files covered by application/octet-stream, only workaround is #77, #78 does not appear to work.
Same issue with my Joomla site. Tried everything above, did a bit more searching then added this to the .htaccess. Make sure you clear your browser cache.

<FilesMatch "\.(?i:pdf)$">
  ForceType application/octet-stream
  Header set Content-Disposition attachment

Just for the record: I had this problem, but it seems to me that Chrome is just more  picky, than IE and Firefox, regaring the syntaxs af the Content-Disposition.

E.g. by mistake I had "Content-Disposition:" instead of "Content-Disposition" and it this cuased Chrome to cancel.

Duble pling around the filename may be requried to for Chrome, but not in other browsers.

#87 works as expected, fantastic! Thanks.

Comment 90 by, Jul 8 2013

Same issue. After disabling "Chrome PDF Viewer" plugin everything works as expected.
 Issue 262910  has been merged into this issue.
Project Member

Comment 92 by, Jul 23 2013

r213119 | | 2013-07-23T15:16:20.578219Z

Changed paths:

Don't override application/octet-stream MIME type.

When enumerating candidate plug-ins for handling a document,
PluginList::GetPluginInfoArray() attemps to match the MIME type of the
document, and then matches the file type based on the URL. Matching by
file type is done if the MIME type of the document is either empty or if
is application/octet-stream.

This change disallows plugin matching based on file type if the MIME
type is application/octet-stream. This will, for example, prevent from being associated with the PDF plug-in if
it is served with a MIME type of application/octet-stream.

As a side-effect, this brings the BufferedResourceHandler's decision of
whether a resource should be rendered or downloaded closer in line with

BUG= 104331 

Review URL:
Labels: M-30
Status: Fixed

Comment 94 by Deleted ...@, Aug 27 2013

I have the same issue with the latest version (29.0.1547.62 m) when i try to export a .xls file
Labels: Restrict-AddIssueComment-EditIssue
The fix will be available starting with Chrome/Chromium 30.x. Please open a new issue if you are seeing similar issues with versions of Chrome 30 or above.

The supported means of indicating that a resource must be downloaded is to use the Content-Disposition header field (

Sign in to add a comment