3

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

8
  • 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?
    – MrWhite
    Nov 5, 2011 at 17:01
  • 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... Nov 6, 2011 at 18:37
  • Have your users check the bottom of their Chrome window. It's possible that the file is being denied by Chrome.
    – laebshade
    Nov 6, 2011 at 19:33
  • 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?
    – MrWhite
    Nov 6, 2011 at 22:49
  • @laebshade: Nothing is displayed at the bottom of their Chrome window. Nov 7, 2011 at 14:43

3 Answers 3

6
+50

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.

2
1

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.

1
  • 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. Nov 10, 2011 at 15:09
0

I would highly suggest to try to use another video encoding such as MPEG, OGG/OGV, WebM and perhaps a Flash fallback. In fact, it would be best to give alternative choices to the user. Modern browsers are going to be focusing on the HTML5 standard. So have a look at how you can manage the different video codecs in HTML5.

A Windows Media Video (WMV) file is proprietary to Microsoft and some users might not have the Windows Media Player plugin for Chrome.

From Google Answers:

If a page simply links to Windows media files (e.g. .asf or .asx files), you might not see a prompt to download the Windows Media Player plug-in.

Also, you may want to check if there is any difference when the links ar absolute or relative.

1
  • We already have fallbacks in the form of FLV and M4V. For the affected users, downloads fail for all video file types. Nov 10, 2011 at 15:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.