为什么Chrome取消302下载？ [英] Why Does Chrome Cancel 302 Downloads?
问题描述
编辑：在解决了可能导致或可能不会导致问题的一些问题后，进一步的测试表明，受影响的用户无法直接下载文件。这已经促使网站管理员Stackexchange上的这个问题。我接受了似乎可以解决问题的答案，是否重定向。
我有一个脚本，用于处理我的基于订阅的视频网站的下载。基本上，脚本根据数据库检查会话和/或IP来识别用户，然后根据数据库检查所请求的视频文件以验证用户应该有权访问。根据这些检查的结果，脚本使用头（'location：[blah]'）; 来发送用户到文件或发送给他们一个错误页面。
在IE，Firefox和Chrome的一些实例中，一切正常。在其他Chrome浏览器中，用户看到下载完全失败。我发现对于这些用户，Chrome会自动取消由标头（）; 调用所做的302重定向，防止文件下载。
为什么会发生这种情况？我可以做些什么呢？
编辑：这是原始标题，从失败的机器上的Fiddler看到下载。
要求：
GET /download_video.php?t=Nodeg004&format=wmv HTTP / 1.1
主机：www.mysite.com
连接：保持活动
用户代理：Mozilla / 5.0（Windows NT 6.0）AppleWebKit / 535.2（KHTML，如Gecko）Chrome / 15.0.874.106 Safari / 535.2
接受：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 =（转介）| utmcmd =转介| utmcct = / l.php
响应：
HTTP / 1.1 302临时移动
日期：2011年11月4日星期五16:22:05 GMT
服务器：Apache
位置：http://www.mysite.com/videos/zh4ZcnzIWJpni8tG5CzG/Nodeg004.wmv
Content-Length ：0
Connection：close
Content-Type：text / html
请求：
GET /videos/zh4ZcnzIWJpni8tG5CzG/Nodeg004.wmv HTTP / 1.1
主持人： www.mysite.com
连接：保持活跃
用户代理：Mozilla / 5.0（Windows NT 6.0）AppleWebKit / 535.2（KHTML，如Gecko）Chrome / 15.0.874.106 Safari / 535.2
接受：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：zh-CN，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 =（转介）| utmcmd =转介| utmcct = / l.php
响应：
HTTP / 1.1 200 OK
日期：周五，2011年11月4日16:22:05 GMT
服务器：Apache
上次修改时间：Wed，28 Sep 2011 13:28:50 GMT
ETag：180cc25a-5700e91-4ae005f5ce880
Accept-Ranges：bytes
Content-Length：91229841
Keep-Alive：timeout = 10，max = 30
连接：Keep-Alive
Content-Type ：application / octet-stream
似乎是你发送'位置'标题而不是标准的'位置'标题。
我做了一个快速测试，似乎证实了这一点，但我仍然无法相信它，所以我做了一个快速的网络搜索，发现其他人确认Chrome确实是一个坚持者，它不会接受带有错误大小写的HTTP标头。
关于PHP手册的评论提及IE7同样的怪癖。
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.
这篇关于为什么Chrome取消302下载？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
