Edit: After addressing some issues that may or may not have been causing problems, further testing revealed that the affected users are unable to download files, even directly. That has prompted this question on Webmasters Stackexchange. I am accepting the answer that seems likely to have fixed the problem, were it all about the redirection.
I have a script which processes downloads for my subscription-based video site. Basically, the script checks session and/or IP against the database to identify the user, and then checks the requested video file against the database to verify that the user should have access. Based on the results of these checks, the script uses header('location: [blah]'); to either send the user to the file or to send them to an error page.
Everything works fine in IE, Firefox, and some instances of Chrome. In other instances of Chrome, users see the downloads fail completely. I have found that for these users, Chrome is automatically cancelling the 302 redirect made by the header(); call, preventing the file from downloading.
Why is this happening? What can I do about it?
Edit: Here are the raw headers, as seen from Fiddler on a machine that failed the download.
Request:
GET /download_video.php?t=Nodeg004&format=wmv HTTP/1.1
Host: www.mysite.com
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows NT 6.0) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.874.106 Safari/535.2
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Referer: http://www.mysite.com/phpBB3/viewtopic.php?f=3&t=6847
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie: phpbb3_cmviy_u=698; phpbb3_cmviy_k=; phpbb3_cmviy_sid=0c2fd249ff50c922beb1c7f88437c283; style_cookie=printonly; __utma=174624884.1269868282.1272079241.1320418809.1320423695.199; __utmb=174624884.5.10.1320423695; __utmc=174624884; __utmz=174624884.1319811247.179.134.utmcsr=facebook.com|utmccn=(referral)|utmcmd=referral|utmcct=/l.php
Response:
HTTP/1.1 302 Moved Temporarily
Date: Fri, 04 Nov 2011 16:22:05 GMT
Server: Apache
location: http://www.mysite.com/videos/zh4ZcnzIWJpni8tG5CzG/Nodeg004.wmv
Content-Length: 0
Connection: close
Content-Type: text/html
Request:
GET /videos/zh4ZcnzIWJpni8tG5CzG/Nodeg004.wmv HTTP/1.1
Host: www.mysite.com
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows NT 6.0) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.874.106 Safari/535.2
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Referer: http://www.mysite.com/phpBB3/viewtopic.php?f=3&t=6847
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie: phpbb3_cmviy_u=698; phpbb3_cmviy_k=; phpbb3_cmviy_sid=0c2fd249ff50c922beb1c7f88437c283; style_cookie=printonly; __utma=174624884.1269868282.1272079241.1320418809.1320423695.199; __utmb=174624884.5.10.1320423695; __utmc=174624884; __utmz=174624884.1319811247.179.134.utmcsr=facebook.com|utmccn=(referral)|utmcmd=referral|utmcct=/l.php
Response:
HTTP/1.1 200 OK
Date: Fri, 04 Nov 2011 16:22:05 GMT
Server: Apache
Last-Modified: Wed, 28 Sep 2011 13:28:50 GMT
ETag: "180cc25a-5700e91-4ae005f5ce880"
Accept-Ranges: bytes
Content-Length: 91229841
Keep-Alive: timeout=10, max=30
Connection: Keep-Alive
Content-Type: application/octet-stream
Rather surprisingly, the problem seems to be that you are sending a ‘location’ header instead of the standard ‘Location’ header.
I did a quick test that seemed to confirm this, but I still couldn’t believe it, so I did a quick web search and found someone else confirming that Chrome is indeed such a stickler that it won’t accept an HTTP header with the wrong case.
A comment on the PHP manual mentions IE7 having the same quirk.