ID:               24033
 Comment by:       webmaster at webtechies dot net
 Reported By:      thomas at nimstad dot com
 Status:           Bogus
 Bug Type:         Sockets related
 Operating System: Win32
 PHP Version:      4.3.2
 New Comment:

I can say that some of you guys here are really life savers.

I was working on my scripts for hours and I could see that there is
something wrong with the length of the pockets it reads but couldn't
find anything in the manual. And my codes were working until my ISP
re-build the server.

Then I found the answer here.

Thanks guys. Hopefully the fix will stay working in next version too.


Previous Comments:
------------------------------------------------------------------------

[2003-06-13 18:20:58] [EMAIL PROTECTED]

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.


------------------------------------------------------------------------

[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().


------------------------------------------------------------------------

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

Reply via email to