ID:               16892
 Comment by:       netscoutt at gmail dot com
 Reported By:      giwarden at ucla dot edu
 Status:           No Feedback
 Bug Type:         Documentation problem
 Operating System: Linux
 PHP Version:      4.2.0
 New Comment:

Unable to View IMAGE of  The internal structure of PHP in Zend 1 on
Site online as well as the in .chm file of Documentation...
please...fix that!


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

[2002-10-14 19:26:50] phpdoc at lists dot php dot net

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

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

[2002-09-24 16:08:32] [EMAIL PROTECTED]

Can you try a non-stable snapshot from http://snaps.php.net and see if
that behaves a little better?

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

[2002-07-02 16:42:27] [EMAIL PROTECTED]

Hmm...strange combination of OSses, anyway, I can't reproduce this
error with my Redhat-system here, and IMHO the 4th parameter of
fsockopen is sufficiently documented. Still leaving this as "verified" 
(during Bughunt)


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

[2002-04-29 06:45:01] [EMAIL PROTECTED]

The timeout parameter is the timeout for the connection setup.  To set
a timeout for socket reads/writes, use the socket_set_timeout()
function.
I'm making this a documentation problem, because we don't make this
very clear.

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

[2002-04-28 22:16:12] giwarden at ucla dot edu

I'm having trouble reading the data from responses over socket
connections.

For instance, this code (similar to that on the online docs for
fsockopen, example 1),

$fp = fsockopen ("localhost", 80, $errno, $errstr, 10);
if (!$fp) {
    echo "$errstr ($errno)<br>\n";
} else {
    fputs ($fp, "GET / HTTP/1.0\r\nHost: localhost\r\n\r\n");
    while (!feof($fp)) {
        echo fread ($fp,128);
    }
    fclose ($fp);
}

results in a timeout on the fread line (even if I let it run for 300
seconds). I also tried the udp example (example 2,
"fsocketopen("udp://127.0.0.1"...) on the documentation page and had the
same problem. Also note that the fourth parameter to the fsockopen
doesn't seem to be working in this case since this code took 300 seconds
to timeout, not the 10 specified. The CPU usage by php went to 100%
during the attempted excution of this code.

I have the same problem if I try using fopen to open a web page and
read the data (as in the below code). It always hangs on the fread or
fgets of the file pointer with the response in it. I know the remote
service (e.g., the web server) is actually sending a response string
because I can see it in the server log.

My hardware is a bit unusual. I'm running SuSe linux kernel
2.4.7-SuSe-SMP under VM on an IBM mainframe. I had these errors with php
versions 4.2.0, 4.1.2, and 4.0.6. 

I tried to replicate the problem on an intel box with RedHat 7.2 kernel
2.4.9 and php 4.0.6, but failed. The most abnormal behaviour I could
find on that platform was that "fopen" and then "fread" of remote or
local web pages took *way* too long.

For instance, this code eventually got the desired response, but it
took about 20-24 seconds:

$fp = fopen("http://localhost/";, "r");
$text = fread($fp, 20);
fclose($fp);
echo $text;

If I used fsockopen (e.g., with the first piece of code above) on this
box it ran in less than a second and gave the expected response. 

Any help is much appreciated. I really need to figure out how to read
data over sockets on that first machine.

Thanks,
Graham Warden
[EMAIL PROTECTED]

p.s.
This is somewhat related to my previous bug post (#10996) about a year
ago.

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


-- 
Edit this bug report at http://bugs.php.net/?id=16892&edit=1

Reply via email to