[wp-trac] [WordPress Trac] #14730: ms-files.php required ob_clean() and flush()
WordPress Trac
wp-trac at lists.automattic.com
Wed Sep 8 10:21:56 UTC 2010
#14730: ms-files.php required ob_clean() and flush()
--------------------------+-------------------------------------------------
Reporter: pj_mfc | Owner:
Type: defect (bug) | Status: new
Priority: normal | Milestone: Awaiting Review
Component: Multisite | Version:
Severity: normal | Keywords:
--------------------------+-------------------------------------------------
Changes (by mikelittle):
* cc: wordpress@… (added)
Comment:
I encountered a similar problem on two different installations of
WordPress when upgrading from wpmu 2.9.2 to wp 3.0.1.
This is a long entry, but hopefully has plenty of concrete information.
'''On the first server:'''
* Ubuntu 8.04.4 LTS
* PHP Version 5.2.4-2ubuntu5.10
* Apache/2.2.8 (Ubuntu) DAV/2 SVN/1.4.6 PHP/5.2.4-2ubuntu5.10 with
Suhosin-Patch proxy_html/3.0.0
I first noticed ms-files.php cutting off an image at 16k. Here is the
output of a wget:
{{{
wget http://ias.version-control.com/files/2010/01/DarthVader.png
--2010-09-08 10:00:42-- http://ias.version-
control.com/files/2010/01/DarthVader.png
Resolving ias.version-control.com... 87.117.205.87
Connecting to ias.version-control.com|87.117.205.87|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 16631 (16K) [image/png]
Saving to: `DarthVader.png'
98% [=...==> ] 16,384 --.-K/s in 0.04s
2010-09-08 10:00:42 (365 KB/s) - Connection closed at byte 16384.
Retrying.
}}}
Adding a call to flush() after readfile($file) solved the problem.
{{{
wget http://ias.version-control.com/files/2010/01/DarthVader.png
--2010-09-08 10:01:50-- http://ias.version-
control.com/files/2010/01/DarthVader.png
Resolving ias.version-control.com... 87.117.205.87
Connecting to ias.version-control.com|87.117.205.87|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 16631 (16K) [image/png]
Saving to: `DarthVader.png.1'
100%[=...==>] 16,631 --.-K/s in 0.05s
2010-09-08 10:01:50 (343 KB/s) - `DarthVader.png.1' saved [16631/16631]
}}}
I then noticed the problem (or rather the client did) on the live site
(which had the call to flush in place) on a larger file.
'''On the live server:'''
* Red Hat Enterprise Linux Server release 5.4 (Tikanga)
* PHP Version 5.1.6
* Apache/2.2.3 (Red Hat)
ms-files.php was cutting off at 1097728 bytes. Here is the output of a
wget:
{{{
wget http://imascientist.org.uk/files/2010/01/Im-a-Scientist-evaluation-
report.pdf
--2010-09-07 16:38:34-- http://imascientist.org.uk/files/2010/01/Im-a
-Scientist-evaluation-report.pdf
Resolving imascientist.org.uk... 94.236.120.219
Connecting to imascientist.org.uk|94.236.120.219|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1099885 (1.0M) [application/pdf]
Saving to: `Im-a-Scientist-evaluation-report.pdf.4'
99% [=...===> ] 1,097,728 1.06M/s in 1.0s
2010-09-07 16:38:36 (1.06 MB/s) - Connection closed at byte 1097728.
Retrying.
}}}
I went back to the first server and tried the larger file. Same result
without the flush() in place. Here is the output of a wget:
{{{
wget http://ias.version-control.com/files/2010/01/Im-a-Scientist-
evaluation-report.pdf
--2010-09-08 09:53:23-- http://ias.version-control.com/files/2010/01/Im-a
-Scientist-evaluation-report.pdf
Resolving ias.version-control.com... 87.117.205.87
Connecting to ias.version-control.com|87.117.205.87|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1099885 (1.0M) [application/pdf]
Saving to: `Im-a-Scientist-evaluation-report.pdf'
99% [==...==> ] 1,097,728 633K/s in 1.7s
2010-09-08 09:53:25 (633 KB/s) - Connection closed at byte 1097728.
Retrying.
}}}
'''With the flush() in place the large file also downloads
successfully.'''
Back on the live server, I spotted that even small files do not download
with the flush in place: here is wget again for a much smaller file:
{{{
wget http://imascientist.org.uk/files/2010/04/ias-ticket-wallet-18th-
june-09-thumbnail1-150x117.jpg
--2010-09-08 10:49:24-- http://imascientist.org.uk/files/2010/04/ias-
ticket-wallet-18th-june-09-thumbnail1-150x117.jpg
Resolving imascientist.org.uk... 94.236.120.219
Connecting to imascientist.org.uk|94.236.120.219|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 9297 (9.1K) [image/jpeg]
Saving to: `ias-ticket-wallet-18th-june-09-thumbnail1-150x117.jpg.1'
88% [=...==> ] 8,192 --.-K/s in 0.009s
2010-09-08 10:49:24 (925 KB/s) - Connection closed at byte 8192. Retrying.
}}}
Here it is cutting off at 8k rather than 16k
This time after much googling, I found a replacement readfile here
http://us2.php.net/manual/en/function.readfile.php#88549
Adding that function to ms-files.php and calling that in place of readfile
solves the problem on the live site: both small and large files are
downloaded ok.
In both cases the problem did not occur with WordPress MU 2.9.2.
In neither case has the OS, PHP, or Apache changed. They are both
dedicated servers and I have full control.
I noticed that for both the large and small files, the cut off point was
an 'exact' size (16K and 67 x 16K for server 1, 8K and 134 x 8K for the
live server), so this is probably an interaction with a PHP buffer
somewhere.
'''Summary:'''
ms-files.php call to readfile() seems to be not flushing it's last buffer
for both large and small files.
On the test server, a call to flush() solves the problem for both large
and small files.
On the live server, the call to flush was not enough for small or large.
The replacement readfile function was required.
The servers have different OS, different version of PHP and different
versions of Apache, so this is not a simple "bug in version x of y" issue.
The difference between blogs.php from mu 2.9.2 and ms-files.php in wp
3.0.1 is minimal, but something in the 3.0.1 environment is triggering
this issue.
I hope this helps someone get to the heart of the issue.
--
Ticket URL: <http://core.trac.wordpress.org/ticket/14730#comment:2>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software
More information about the wp-trac
mailing list