What could keep Chrome from downloading files?

Question

I run a subscription-based site for poker training videos. In the recent past, some portion of our subscribers have developed problems downloading our videos. The affected users are exclusively seeing problems while using Chrome as their web browser, however there are other users who use Chrome with no problem.

Here is the exact behavior they are seeing:

• Pasting the url of a video file directly to their browser produces about:blank and the file does not download
• Clicking the link normally produces no result (e.g. it behaves like a dead link)
• Right-clicking the link and opening in a new tab/window produces about:blank and the file does not download
• Right-clicking the link and choosing Save-As produces a 5 to 10 second delay, after which they get a Save As dialog. After they choose a location, the download proceeds at full speed.

Again, this problem has only presented itself for a subset of users browsing with Chrome. All affected users have the latest version of Chrome, but so do some of the unaffected users. All affected users have Windows Vista or Windows XP. As far as we can tell (small sample size), none of the affected users have Windows 7 and none of our users on Windows 7 have been affected.

What could be causing this problem? How could it be solved?

Edit: Here is a copy of the headers from one of these downloads.

HTTP/1.1 200 OK
Date: Sun, 06 Nov 2011 18:35:56 GMT
Server: Apache
Last-Modified: Mon, 24 Oct 2011 11:57:29 GMT
ETag: "180cc292-5229699-4b00a208b3c40"
Accept-Ranges: bytes
Content-Length: 86152857
Keep-Alive: timeout=10, max=29
Connection: Keep-Alive
Content-Type: application/octet-stream

Edit: Some updates. Chrome extensions do not seem to affect this. One of the affected systems was upgraded from Windows XP to Windows 7, with no other changes made. That system now downloads properly. This issue doesn't only affect the WMV videos. It happens with FLV and M4V as well. A sample file is at http://www.grinderschool.com/videos/zbn9Y7TbeWcUbCPFNnLd/Carroters001.wmv

Solution 1

You are sending the Content-Type: application/octet-stream header, presumably hoping to trigger the browser to download the file instead of letting the user view it. This however is not really the best way. You are better of with sending the correct content type and add a content disposition header, like so:

Content-Type: video/mp4
Content-Disposition: attachment; filename=instruction-video.mp4

How to send this header depends on your server platform.

Solution 2

Google Chrome uses the Safe Browsing API by default (blog post here). The Safe Browsing API maintains a list of potentially malicious sites. It is possible that the page has been flagged as malicious. Google offers another tool called Webmaster Tools that allows the webmaster to verify ownership of a site through a review process, then mark a site as not malicious (details here).

At a minimum, you could start by adding the site in Webmaster Tools and checking under Diagnostics --> Malware to see if it has been added as a malicious site.

Comments

[MrWhite]

What do you mean exactly by "download"? Should the user be presented with a "Save As" dialog so they download the file and save it to their computer OR should the file stream and be viewable directly within the browser? What type (mime-type) of file is it? Are you (or the server) sending the correct response headers for the file's mime-type? Are the users being redirected to about:blank? Or are the users just presented with a blank response? In which case is the browser timing out?

[Jeffrey Blake]

I would prefer a Save-As dialog. We have other links that take them to imbedded streaming players. The file is a WMV file. Users are not redirected to about:blank - that is simply what displays when they open in a new window/tab. I honestly don't know about the response headers. I believe they are correct, but I could be wrong. I don't know how to set them, but I'll edit to show what mine look like (according to Chrome's developer Tools). Though this is on my system, where the downloads are working...

[comco]

Have your users check the bottom of their Chrome window. It's possible that the file is being denied by Chrome.

[MrWhite]

Presumably it is consistent? In that a user who has problems always has problems? What is the browser setting for Downloads - Is the option "Ask where to save each file before downloading" checked?

[Jeffrey Blake]

@laebshade: Nothing is displayed at the bottom of their Chrome window.

[Jeffrey Blake]

@w3d: It is consistent - all users known to be effected always have this problem. Will check on their browser setting for downloads, but if you're getting at changing things so that they choose the directory instead of having it auto-save to their downloads directory, that is not the problem. I'd be satisfied with either of those behaviors.

[Sina Fathieh]

alright, can you give more details about your server side : what language / database and server type , because I think whatever the problem is, you can benefit from a "force download"

[DisgruntledGoat]

Have you tried disabling all Chrome extensions temporarily? Do you have an example URL? (Doesn't matter if it's not actually accessible because of the subscription thing.) Although if you are able to create a public test case on a small video that could be useful.

[Jeffrey Blake]

I'll check into this, but...Would this somehow not affect Chrome users on Windows 7? It seems like it would affect all Chrome users if this were the issue.

[Jeffrey Blake]

I will definitely check into this. I set those headers in .htaccess for video downloads, for exactly the reason you guessed.

[Jeffrey Blake]

We already have fallbacks in the form of FLV and M4V. For the affected users, downloads fail for all video file types.

[Jeffrey Blake]

THANK YOU! This solved it. Specifically, I used the content disposition settings for .htaccess that are mentioned in 99seconds.net/2009/09/force-a-pdf-to-download-with-htaccess