Some background: I run a subscription-based poker strategy video website. Our videos range in length from 30 mins up to 80 mins, and in size from 20MB up to 500MB. The site is on a shared server with hostmonster.com

One of my users is having problems downloading some of the larger video file. He reports problems with anything over 100MB. Basically, he's only getting part of the file, which means that the video stops before the end. He has tried multiple computers from multiple locations. He reports that he is able to successfully download 500MB files from other sites.

He is using Internet Explorer (version unknown) as his browser. I have suggested that he try Firefox or Chrome to see if their download managers work any better for him, but as of yet I have not heard anything back.

He has also reported that his downloads do not report any filesize. I see the same thing (no file size reported), but I have not experienced any problems with the downloads themselves.

We pass the downloads through a php script which verifies login information and records the download to our database before returning the file. I suspect this is why there is no filesize reported.

What else should I ask the user? What other things could he or I try?

  • I'll note that another user reported a similar problem around a year ago, however he left the site before we were able to resolve the issue. Relevant info from that is that we did not have the php script in place at that time, so whether or not that is affecting the download size reporting, it is probably not the cause of this issue. – Jeffrey Blake Apr 10 '10 at 0:28
  • So it turns out the other machines he tested were also on the same ISP as he uses (AT&T DSL in San Antonio). Don't know what that tells us, save that the problem is definitively between our server and his ISP. – Jeffrey Blake Apr 11 '10 at 1:45

The issue was finally resolved when I began changing settings for server configuration, at prompting from responses to the StackOverflow question ( https://stackoverflow.com/questions/2617190/php-file-serving-script-unreliable-downloads )

Looking further into the filesize issue, I found that the size was being set correctly in the script, but that was not being reflected in the headers returned to the browser. Rather, the headers that were being returned were:


GET /download_video_test.php?t=KillsAids021&format=wmv HTTP/1.1
Host: www.grinderschool.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20100401 Firefox/3.6.3 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Cookie: style_cookie=printonly; phpbb3_7c544_u=2; phpbb3_7c544_k=44b832912e5f887d; phpbb3_7c544_sid=e8852df42e08cc1b2250300c2897f78f; __utma=174624884.2719561324781918700.1251850714.1270986325.1270989003.575; __utmz=174624884.1264524375.411.12.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=low%20stakes%20poker%20videos; phpbb3_cmviy_k=; phpbb3_cmviy_u=2; phpbb3_cmviy_sid=d8df5c0943863004ca40ef9c392d371d; __utmb=174624884.4.10.1270989003; __utmc=174624884

HTTP/1.1 200 OK
Date: Sun, 11 Apr 2010 12:58:02 GMT
Server: Apache/2.2.14 (Unix) mod_ssl/2.2.14 OpenSSL/0.9.8l DAV/2 mod_auth_passthrough/2.1 FrontPage/
X-Powered-By: PHP/5.2.11
Content-Disposition: attachment; filename=KillsAids021.wmv
Vary: Accept-Encoding
Content-Encoding: gzip
Keep-Alive: timeout=10, max=30
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: video/x-ms-wmv

In the end, it turned out that the problem was the gzip compression which was automatically being applied by my webserver for any php generated content. Below are the steps that I took to rectify it:

First, I established a new php.ini to control my individual folder on the shared server. Then I confirmed that my php.ini file was configured with zlib.output_compression = Off That didn't solve it.

Next I looked at the specific settings for Apache. Since it's a shared server, I couldn't directly access any of the Apache configuration files, but I was able to control how I want my site handled, by creating a .htaccess file and adding the line: SetEnvIfNoCase Request_URI \.php$ no-gzip dont-vary

With this line, none of my php will be compressed. That did the trick. The downside to this solution is that it will result in larger file sizes and bandwidth usage for the php pages on my site. A welcome upside is that it will reduce our CPU consumption (which is the only factor of being on a shared server that has been a limiting factor thus far). In the end, this is definitely a welcome change!


Because of the extremely low appearance of this problem, i would sugest, that is has something to do with the internet access of the specific user. You told us, that the user tried it from multiple computers. What was the result of that test? Did it work from other machines?

  • That's what I thought too, but it bothers me that it only seems to affect his access to our server. We solved the issue for one specific file by uploading it to the server of one of our business partners. The user was able to download from their server with no problems. He experienced the same problem when trying to download from our site from all machines that he tried. I haven't yet heard back on whether these other machines were using the same ISP as he uses. – Jeffrey Blake Apr 10 '10 at 1:46

Trying other browsers or download managers didn't work. In the end, I had the user try direct downloads and that did the trick. So apparently the problem is somewhere in our php-based fileserving script.

I'm marking this question answered for ServerFault. If I can't figure out the problem with the script, then I may post again on StackOverflow.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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