问题下载：缓慢和/或失败 [英] Problem with downloads: slow and/or fails

问题描述

我有以下脚本，让访客下载文件：

I have the following script to let a visitor download a file:

header( 'Content-Type: application/octet-stream' );
header( 'Content-Transfer-Encoding: binary' );
header( 'Content-Disposition: attachment; filename=' . $fileName );
header( 'Content-Length: ' . filesize( $filePath ) );
header( 'Content-Description: Download' );
header( 'Cache-Control: private' );
header( 'Pragma: no-cache' );
header( 'Expires: 0' );

readfile( $filePath );
exit();

它不工作得很好。 （我也把文件名中的报价，同样的结果）。

It doesn't work very well. (I've also put the filename in quotes, same result).

它的行为非常缓慢，有时甚至下载暂停。在Opera尤其是，它会暂停对下载的99％。有时它甚至会立即显示99％完成，然后开始下载，并在约34％停止。

It behaves very slow, and sometimes the downloads even halt. In Opera especially, it halts on 99% of the download. Sometimes it even immediately shows 99% completed, then it starts downloading and halts at around 34%.

该服务器是一个共享主机，Mac OS X服务器。

The server is a shared host, Mac OS X server.

通过使用Firefox的Live HTTP头插件，我已经注意到了服务器将aditional的标题来回应：

With using Firefox's Live HTTP headers add-on, I've noticed the server adds aditional headers to the response:

HTTP/1.1 200 OK
Date: Thu, 18 Feb 2010 09:27:25 GMT
Server: Apache
X-Powered-By: PHP/5.2.12
Content-Transfer-Encoding: binary
Content-Disposition: attachment; filename=test.psd
Content-Length: 398635
Content-Description: Download
Cache-Control: private
Pragma: no-cache
Expires: 0
Content-Encoding: gzip // <-- expecially this one,
Vary: Accept-Encoding // <-- this one,
MS-Author-Via: DAV // <-- and this one
Keep-Alive: timeout=10, max=100
Connection: Keep-Alive
Content-Type: application/octet-stream

难道这是问题的原因是什么？

Could these be the cause of the problem?

当我在我的本地运行脚本一切工作正常。此外，当我直接从这个主机下载文件，速度也很好，流畅。

When I run the script on my localhost everything works fine. Also, when I directly download files from this host, the speed is also fine and fluent.

我真的就这一个相当无能。你的帮助是appeciated。谢谢你在前进。

I'm really rather clueless on this one. Your help is appeciated. Thank you in advance.

更新：

我想我已经到了瓶颈收窄的问题。 Web服务器会自动的gzip COM presses输出。当我删除了的Content-Length 头从我的PHP脚本开始一切顺利下载。这是有道理的：在内容长度的值不实际的gzip压缩输出了相匹配。在PHP中我读了uncom pressed文件大小设置的Content-Length 头，但事后，阿帕奇COM presses它，这可能是那里的浏览器哽咽。

I think I have narrowed the problem down to the bottleneck. The webserver automatically gzip compresses the output. When I removed the Content-Length header from my PHP script everything started downloading smooth. This makes sense: The value of the Content-Length doesn't match the actual gzipped output anymore. In PHP I read the uncompressed filesize to set the Content-Length header, but afterwards, Apache compresses it, and this is probably where the browsers choked.

我会遵循这个问题了一个有关如何设置正确的的Content-Length 头大小的问题时，Web服务器会自动的gzip COM presses输出。

I'll follow this question up with a question about how to set the correct Content-Length header size when the webserver automatically gzip compresses output.

推荐答案

我已经将问题范围缩小到了瓶颈。 Web服务器会自动的gzip COM presses输出。当我从我的PHP脚本的一切删除Content-Length头开始下载流畅。这是有道理的：内容长度的值不实际的gzip压缩输出了相匹配。在PHP中我读pssed文件大小设置Content-Length头的uncom $ P $，但事后，阿帕奇COM presses它，这可能是那里的浏览器哽咽。

I have narrowed the problem down to the bottleneck. The webserver automatically gzip compresses the output. When I removed the Content-Length header from my PHP script everything started downloading smooth. This makes sense: The value of the Content-Length doesn't match the actual gzipped output anymore. In PHP I read the uncompressed filesize to set the Content-Length header, but afterwards, Apache compresses it, and this is probably where the browsers choked.

这篇关于问题下载：缓慢和/或失败的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！