Page 1 of 1

Downloads fail when content-length header is sent

Posted: Sat Jan 13, 2007 11:39 pm
by pzbrawl
feyd | Please use

Code: Select all

,

Code: Select all

and [syntax="..."] tags where appropriate when posting code. Your post has been edited to reflect how we'd like it posted. Please read:  [url=http://forums.devnetwork.net/viewtopic.php?t=21171]Posting Code in the Forums[/url] to learn how to do it too.[/color]


The following code (run from a shared linux/apache web server) fails at the end of the download with a "source file could not be read" error at the client.

Code: Select all

$path = "xxx/";
    $file = "yyy.zip";
    $filetype = "application/x-zip-compressed";
    $fsize = filesize( $path . $file );
    header( "Content-Disposition: attachment; filename=\"$file\"");
    header( 'Content-type: '. $filetype );
    header("Content-Length: $fsize" );  
    header( 'Pragma: no-cache' );
    header( 'Expires: 0' );
    return @readfile( $path . $file );
When the content-length header is commented out, some users can download successfully, while others get incomplete zips.

Could anyone suggest, please, what might be going on here? Thanks.

P.


feyd | Please use

Code: Select all

,

Code: Select all

and [syntax="..."] tags where appropriate when posting code. Your post has been edited to reflect how we'd like it posted. Please read:  [url=http://forums.devnetwork.net/viewtopic.php?t=21171]Posting Code in the Forums[/url] to learn how to do it too.[/color]

Posted: Sun Jan 14, 2007 12:18 am
by feyd
Have you tried other content types?

Posted: Thu Jan 18, 2007 12:57 pm
by pzbrawl
Setting type to "application/octet-stream" or "encoding/x-compress" also yields read errors when a content length header is sent, and yields an invalid archive for some users when length is not set.

Setting type to "application/gzip" gets rid of the error report when length is set but yields an invalid zip.

Could anyone please suggest what might be going on?

Posted: Thu Jan 18, 2007 3:19 pm
by feyd
What is the return for?

Your "expires" header is invalid.

Posted: Thu Jan 18, 2007 3:30 pm
by pzbrawl
'return' returns the result to the calling function.

Removing the 'Expires:' header makes no difference.

Can anyone suggest what might be wrong?

Posted: Thu Jan 18, 2007 3:40 pm
by feyd
Are you absolutely, 100% sure no extra data is getting into the stream?

Get a local copy from the server of the real file, then get a copy from this script. Use some editor (or other tool) to compare the files.

Posted: Thu Jan 18, 2007 4:26 pm
by pzbrawl
Before being ftp'd to the server, the file is 7,532,284 bytes. A valid archive.

Downloaded from the server to our test machines _without_ the length header, the result file is 7,534,429 bytes long and opens correctly. The extra 2145 bytes in the download is the generated HTML code of the PHP download page. On some users' boxes, however, a download without the length header truncates to about 1.2MB.

Downloaded to our test machines _with_ the length header, the file is 7,501,994 bytes long, 30290 bytes shorter than the original, and generates an "unexpected end of archive" error from winrar.

What's going on?

Posted: Thu Jan 18, 2007 5:11 pm
by pzbrawl
And if we used FTP, we get no error but a file that is 10,002 bytes short:

Code: Select all

function dlftp() {
  $path = "xxx/";
  $file = "yyy.rar" ;
  $conn = ftp_connect( "ftpaddress") or die( "Could not connect to ftp server"); 
  @ftp_login( $conn, "user", "pswd" ) or die( "Could not log into ftp server" );
  return @readfile( ftp_get( $conn, $file, $path . $file, FTP_BINARY ));
}
Could this be a server problem?

Posted: Thu Jan 18, 2007 5:18 pm
by feyd
Do the error logs shed any light? How about smaller files?

Posted: Thu Jan 18, 2007 5:47 pm
by pzbrawl
Error logs are empty.

Same behavior with files a tenth the size

Posted: Fri Jan 19, 2007 8:11 am
by feyd
Binary comparisons of the resultant files hasn't shed information either?

Does the server have other compression systems acting on the data?

Posted: Fri Jan 19, 2007 10:07 am
by pzbrawl
See the reply above on file comparisons.

No known server compression.

Posted: Fri Jan 19, 2007 8:56 pm
by feyd
pzbrawl wrote:See the reply above on file comparisons.
I'm not talking about length. I'm talking about the actual data contained within.