|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #1053 Bizarre corruption problem with files gotten by readfile/fpassthru/etc.
Submitted: 1999-01-11 21:09 UTC Modified: 1999-01-12 09:14 UTC
From: q97 at besiex dot org Assigned:
Status: Closed Package: FrontPage related
PHP Version: 3.0.6 OS: Linux 2.0.35
Private report: No CVE-ID: None
 [1999-01-11 21:09 UTC] q97 at besiex dot org
Hello -

I'm having a rather bizarre problem.  Corrupted downloads when fetched by readfile (or fopen/fpassthru/or any other similar-effect mechanism).  AND, it only affects *some* files (not some types and not random files).  I don't understand it at all, and I just don't see how it can be anything other than a bug.  And, if so, it would seem a rather severe one, except that I haven't seen anyone else post about it on any of the lists.


Linux 2.0.34 (or maybe 2.0.35), Apache 1.3.1 (with SSL, via SSLeay 0.9.0b), PHP 3.0.6 (first noticed this behavior under 3.0.5 but upgrading did nothing)

Here is what happens.  

I'll give the simplest example of it.

Header("Content-disposition: filename=".basename($filename));
Header("Content-type: application/octet-stream");
Header("Content-Length ".filesize($filename));


I then access this PHP code by as http://whatever/file.php3?filename=/whatever/

Now, with some files it works fine.  With some other files the download is corrupted.

The nature of the corruption is very strange indeed.  I assumed it was non-binary safe issue, but it doesn't seem to be.

I can provide an actual example problem file, it's 135kb.  (I've had other files give me similar problems, but this is the only one I've made a point of analyzing.)

The file is a WinZip generated zip file (I've successfully downloaded several other (smaller, significant?) WinZip files using the above code with no problems.

Here is the nature of the corruption (as found by using a hex edit program to compare the file gotten through the above code versus the file fetched by FTP).

At position 0 in the corrupted file the extra characters: efb\r\n
At position f0 (3840) the extra characters: \r\n1105\r\n
At position 200d (8205) the extra characters: \r\nffb\r\n
At position 300f (12303) the extra characters: \r\n1005\r\n
At position 401c(16412) the extra characters: \r\nffb\r\n
At position 501e(20510) the extra characters: \r\n1005\r\n
At position 602e(24619) the extra characters: \r\nffb\r\n
It does some other stuff towards the end, I believe.  But, I wrote it down, but can't find that bit of paper now.

If you subtract the positions in the above, between the \r\nffb\r\n and \r\n1005\r\n is 4098 bytes.
If you subtract the positions in the above, between the \r\n1005\r\n and \r\nffb\r\n is 4109 bytes.

Now, before each of the above bits is nothing seemingly important.  It's not like before each bit inserted is at a newline or anything.

Now, I have tried different ways around this, not using readfile, but using fpassthru, and even a for loop with reading in chunks and outputting it.  Didn't work in any case, although I did not analyze each resulting file to see if the same exact corruption occurred.  I do not believe it did.  I believe I downloaded the same file twice using the SAME PHP3 code and got two different results, but I can't say that with 100% certainty.

Now, here is where it gets odd.  Again, some files work (other WinZip generated files worked) but not others.  I just realized I did not try a larger file than this to see if maybe the problem is related to the file size.  Smaller files did work.  It didn't occur to me that it could be size related until now.


- Quincy


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [1999-01-12 09:14 UTC] rasmus
This turned out to be related to the client-side.
PHP Copyright © 2001-2023 The PHP Group
All rights reserved.
Last updated: Wed Sep 27 06:01:24 2023 UTC