Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Issue 104331 Can't download a .pdf file served as binary/octet-stream
Starred by 68 users Reported by jamierm...@gmail.com, Nov 15, 2011 Back to list
Status: Fixed
Owner: asanka@chromium.org
Closed: Jul 2013
Cc: jam@chromium.org, pauljensen@chromium.org, asanka@chromium.org, cbentzel@chromium.org, abarth@chromium.org
Components:
OS: All
Pri: 2
Type: Bug

Blocking:
issue 68356

Restricted
  • Only users with EditIssue permission may comment.


Sign in to add a comment
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. https://s3.amazonaws.com/jamie-chrome-bug/hello.pdf (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
Comment 1 by cbentzel@chromium.org, Nov 18, 2011
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: http://dev.chromium.org/for-testers/providing-network-details

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?  
Comment 2 by pfeldman@chromium.org, Nov 22, 2011
Owner: vsevik@chromium.org
Status: As
Comment 3 by dhw@chromium.org, 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.
f1006c24-11cc-4628-807f-6a19bdfe72ad
90.3 KB View Download
Comment 6 by vsevik@chromium.org, Dec 14, 2011
Cc: cbentzel@chromium.org
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: http://www.google.com/support/forum/p/Chrome/thread?tid=7e4498b78162740a&hl=en
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 r...@yurkowski.net, 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 https://s3.amazonaws.com/worship/production/print/90314/90314_bgt.pdf (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.
5f62feed-eff7-42fa-a0ec-ca06dfd6e01b
385 KB View Download
Oh - this is using 15.0.874.15 dev on OS X 10.6.8
Comment 12 by aljsi...@gmail.com, Jan 5, 2012
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.
Comment 16 by rob...@grupahim.pl, Jan 9, 2012
Same problems here on Chrome 16.0.912.75 m and Windows XP

Comment 17 by rdsmith@chromium.org, Jan 17, 2012
Issue 109172 has been merged into this issue.
Comment 18 by rdsmith@chromium.org, Jan 17, 2012
Issue 109391 has been merged into this issue.
Comment 19 by rdsmith@chromium.org, Jan 19, 2012
Labels: Mstone-19
Comment 20 by rdsmith@chromium.org, Jan 19, 2012
Blocking: 68356
Comment 21 by jamierm...@gmail.com, Jan 20, 2012
One additional note that may help: It seems I can download files if I ctrl-click the link and choose "save link as..."
Comment 22 by jan.pta...@gmail.com, Jan 25, 2012
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.
Comment 26 by rdsmith@chromium.org, Jan 27, 2012
Owner: asanka@chromium.org
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.

Cc: jam@chromium.org abarth@chromium.org
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:

  URL: http://example.com/foo.pdf
  Content-Type: application/octet-stream

  BufferedResourceHandler::ShouldDownload() returns false.
  and
  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 laforge@google.com, 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 dhw@chromium.org, Apr 24, 2012
Issue 124775 has been merged into this issue.
Comment 38 by dhw@chromium.org, 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
Comment 40 by abarth@chromium.org, Apr 30, 2012
"application/force-download" isn't the right way to force a download.  The proper way is to use:

Content-Disposition: attachment; filename=foo.pdf

Comment 41 by brauc...@gmail.com, May 2, 2012
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]
---
Comment 42 by dharani@google.com, May 8, 2012
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.
Comment 43 by asanka@chromium.org, Jun 18, 2012
Labels: -Mstone-21 Mstone-22
Comment 44 by rdsmith@chromium.org, Jun 21, 2012
Blocking: chromium:68356
Cc: rdsmith@chromium.org
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.
Comment 48 by asanka@chromium.org, Aug 24, 2012
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.

Comment 49 by asanka@chromium.org, Sep 11, 2012
Cc: asanka@chromium.org
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.
Comment 51 by asanka@chromium.org, Sep 13, 2012
Owner: pauljensen@chromium.org
Paul is looking into this.
Comment 52 by rdsmith@chromium.org, Sep 21, 2012
Labels: -Mstone-23 Mstone-24
Comment 53 by rdsmith@chromium.org, Oct 17, 2012
Issue 156375 has been merged into this issue.
Owner: asanka@chromium.org
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.
Cc: pauljensen@chromium.org
Comment 56 by dharani@google.com, Nov 5, 2012
Labels: -Mstone-24
Since the bug has moved few times, removing the milestone label. Please target the right milestone.
Comment 57 by bsama...@gmail.com, Nov 8, 2012
My csv export isn't getting prompted to save/download, it's rendered on the screen. 

B
bsamayoa: See issue 152911
I've seen that same problem downloading an xls file with an <a href> and this response headers:
Cache-Control:max-age=0
Connection:Keep-Alive
Content-Disposition:attachment; filename="foo.xls"
Content-Length:6144
Content-Type:application/octet-stream
Date:Thu, 29 Nov 2012 08:23:24 GMT
Expires:Thu, 19 Nov 1981 08:52:00 GMT
Keep-Alive:timeout=5, max=98
Pragma:public
Server:Apache/2.2.22 (Debian)
X-Powered-By:PHP/5.4.4-9

I workarounded it by adding a target to it, if it helps someone ;-)
Comment 60 by rdsmith@chromium.org, Nov 29, 2012
@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 bjf2...@gmail.com, 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:
http://code.google.com/p/chromium/issues/detail?id=132580

I really can't believe this issue is still around.
Comment 62 by asanka@chromium.org, Nov 29, 2012
Owner: ----
Status: Available
I'm not going to be able to get to this anytime soon.

Comment 63 by mjlar...@gmail.com, 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 k...@google.com, 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
Owner: asanka@chromium.org
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 bugdroid1@chromium.org, Mar 10, 2013
Labels: -Area-Internals -Feature-Downloads -Mstone-27 Cr-Internals M-27 Cr-UI-Browser-Downloads
Comment 72 by rapal...@gmail.com, 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 bouc...@stripe.com, 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
@#76

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 kareng@google.com, Apr 15, 2013
Labels: -M-27 MovedFrom-27 M-28
Comment 80 by asanka@chromium.org, Apr 29, 2013
Issue 233927 has been merged into this issue.
Comment 81 by rdsmith@chromium.org, Apr 30, 2013
Cc: -rdsmith@chromium.org
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 bugdroid1@chromium.org, 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.
Cc: -asanka@chromium.org
#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.
Comment 87 by johnno...@gmail.com, Jun 28, 2013
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
</FilesMatch>

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 say...@gmail.com, Jul 8, 2013
Same issue. After disabling "Chrome PDF Viewer" plugin everything works as expected.
Comment 91 by asanka@chromium.org, Jul 22, 2013
Cc: asanka@chromium.org
Issue 262910 has been merged into this issue.
Project Member Comment 92 by bugdroid1@chromium.org, Jul 23, 2013
------------------------------------------------------------------------
r213119 | asanka@chromium.org | 2013-07-23T15:16:20.578219Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/common/plugin_list_unittest.cc?r1=213119&r2=213118&pathrev=213119
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/common/plugin_list.cc?r1=213119&r2=213118&pathrev=213119
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/download/download_browsertest.cc?r1=213119&r2=213118&pathrev=213119
   A http://src.chromium.org/viewvc/chrome/trunk/src/content/test/data/download/octet-stream.abc.mock-http-headers?r1=213119&r2=213118&pathrev=213119
   A http://src.chromium.org/viewvc/chrome/trunk/src/content/test/data/download/octet-stream.abc?r1=213119&r2=213118&pathrev=213119

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
http://example.com/foo.pdf 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
Blink's.

BUG= 104331 

Review URL: https://chromiumcodereview.appspot.com/18364005
------------------------------------------------------------------------
Comment 93 by asanka@chromium.org, Jul 24, 2013
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
Comment 95 by asanka@chromium.org, Aug 27, 2013
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 (http://tools.ietf.org/html/rfc6266).

Sign in to add a comment