ID: 24033
Updated by: [EMAIL PROTECTED]
Reported By: thomas at nimstad dot com
Status: Bogus
Bug Type: Sockets related
Operating System: Win32
PHP Version: 4.3.2
New Comment:
bob at bravenet dot com:
That is just one of the reasons why we reinstated the pre 4.3.x
behaviour.
Please check your history before complaining.
Previous Comments:
------------------------------------------------------------------------
[2003-06-13 17:29:07] bob at bravenet dot com
I absolutely disagree with the conclusion on this bug. To outright
change the functionality of fread like this without any notice
whatsoever and especially in a minor revision is totally irresponsible
as a company.
To date fread has always taken a $length parameter and php handled the
buffering. And the docs still say that it will. When making a change
like this, at a minimum, update the docs so we don't waste a couple
days trying to find out that you changed the functionality of fread.
------------------------------------------------------------------------
[2003-06-06 03:17:06] [EMAIL PROTECTED]
This is your loop:
while (!feof($fp) && $length > 0) {
$size = min(1024, $length);
$reply .= fread($fp, $size);
$length -= $size;
}
It looks wrong to me, since you are not checking the return value of
fread and are just assuming that it read the chunk you asked for.
This is a better loop:
while ($length > 0) {
$size = min(8192, $length);
$data = fread($fp, $size);
if (strlen($data) == 0) {
break; // EOF
}
$reply .= $data;
$length -= strlen($data);
}
It is recommended that you fread() in chunks of 8kb from sockets, as
you will get better performance than using a smaller value. Using a
larger value is wasteful as the streams layer will only allocate in 8KB
chunks; Win32 has a maximum internal packet size of 8KB too.
I'm marking this as bogus since it is the expected behaviour of PHP (I
actually spent a couple of days correcting and testing this for
HTTP/1.1 keep alives).
------------------------------------------------------------------------
[2003-06-06 03:06:27] thomas at nimstad dot com
Ok. Since I'm was not the only having the problem I examined it some
more... here we goes again...
Problem #1: When using a chunk size >= 8192 bytes it's just to
concatenate the data and continue reading (as examplified in the
documentation). So to what I understand, this is not a bug, rather than
a timing issue that fread() returns the number of bytes available at
the moment? Anyway, in this case problem #2 doesn't occurs!!
Problem #2: The fread() still hangs until timeout if I try to read data
in chunks of <= 4096 bytes!!
------------------------------------------------------------------------
[2003-06-06 01:46:52] [EMAIL PROTECTED]
>From the manual:
When reading from network streams or pipes, such as those returned when
reading remote files or from popen() and proc_open(), reading will stop
after a packet is available. This means that you should collect the
data together in chunks as shown in the example below.
A bug existed in 4.3.0-1 that made it "work", so, it's not considered
changed behavior, just a bug. This bug, for example, did not exist in
4.2.3
Regarding Thomas "problem #2", not sure about that, will see what Wez
has to say.
Regarding the last proposed example by PJ, just use
file_get_contents().
------------------------------------------------------------------------
[2003-06-05 14:56:49] PJ at Elitegamer dot com
I too am experiencing this changed behavior. Previously, my code was as
follows:
$contents = fread ($fp, 2097152);
And that would return up to 2mb from the given socket. In my case, the
socket was a fopen() url.
However, when I upgraded to PHP 4.3.2 it would ONLY return 2481 bytes
no matter what. As a quick fix I had to move the fread() inside of a
while loop, in order to fix this issue. Like this:
$contents = "";
while (($data = fread ($fp, 2097152)) !== "")
{
$contents .= $data;
}
The only change on my system and the files being read was my upgrading
to PHP 4.3.2. This definitely appears to be changed behavior of
fread().
-PJ
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/24033
--
Edit this bug report at http://bugs.php.net/?id=24033&edit=1
