Req #52374 [Com]: socket_read(): PHP_NORMAL_READ against user defined string
Edit report at http://bugs.php.net/bug.php?id=52374edit=1
ID: 52374
Comment by: recycling dot sp dot am at gmail dot com
Reported by:bastard dot internets at gmail dot com
Summary:socket_read(): PHP_NORMAL_READ against user defined
string
Status: Open
Type: Feature/Change Request
Package:Sockets related
Operating System: any
PHP Version:5.3.2
Block user comment: N
New Comment:
In most text protocols, the end of line is written \r\n (See http,
POP3,...). Consequently, it requires two consecutive calls using
socket_read() to handle answers from these protocol. The latter call is
only done to bypass the '\n'.
Previous Comments:
[2010-07-19 03:04:39] bastard dot internets at gmail dot com
Note: on the echo line, you may want to replace the end
'$current_line\n' with '.trim($current_line).\n;'. Because of all
the extra line breaks and carriage returns echoed directly from the read
text, the original example might output a bit oddly.
[2010-07-19 02:20:03] bastard dot internets at gmail dot com
Description:
With the assumption that the PHP_NORMAL_READ flag can be used to
basically read in line-by-line, can a 4th optional function argument be
added to allow users to define what exactly denotes an end of line for
their chosen protocol? If this 4th parameter is not passed by the user,
socket_read() could default to it's current behavior.
With PHP_NORMAL_READ set, socket_read() now stops and returns on any of
the first \r, \n, and presumably \0 characters found. Because
protocols would more often use a different character or character chains
to denote end of line - such as HTTP's \r\n - allowing the user to
pass in \r\n to tell socket_read() where to stop and return would help
save extra code to correctly handle message parsing, or having to
confirm and discard any useless character socket_read() grabs next.
Also, the current behavior of socket_read() is to consume and return
that end of line character, which is good. If the above is
implemented, the function should also consume and return everything up
to and and including that user defined string, to avoid infinite loops.
Test script:
---
// read in line-by-line, echoing the first ord and last ord of each line
just to show my point
$conn = socket_accept($s_socket);
socket_set_nonblock($conn) OR
trigger_error(Failed to set non-blocking for accepted connection!,
E_USER_ERROR);
for($current_line = ''; 1;) {
$current_line = socket_read($conn, 4096, PHP_NORMAL_READ);
if ($current_line == '') {
break;
}
echo [Start ord at pos 0: .ord($current_line[0]).; End ord at pos
.(strlen($current_line) - 1).:
.ord($current_line[strlen($current_line) - 1]).]: $current_line\n;
}
Expected result:
With the optional 4th function parameter, the read behavior could be
controlled by the user. For example if a client connected with an HTTP
request, socket_read($conn, 4096, PHP_NORMAL_READ, \r\n) would return
the current header. The next iteration of socket_read() would return
the next header. And, if socket_read() returned only \r\n, this would
denote end of headers section.
Actual result:
--
The test script above shows the undesirable behavior if using something
like HTTP to connect to this server. Line 'echo [Start ord at pos...'
produces an extra line each time. This is because socket_read() stopped
and returned at the first encounter of \r in each header line, and on
the next read, stopped and returned at the first encounter of \n,
which was the very next character in the header line.
--
Edit this bug report at http://bugs.php.net/bug.php?id=52374edit=1
[PHP-BUG] Bug #52811 [NEW]: the notification callback method never gets call when using socket streams
From:
Operating system: *
PHP version: 5.3.3
Package: Streams related
Bug Type: Bug
Bug description:the notification callback method never gets call when using
socket streams
Description:
At least when the context is set to 'tcp' and the socket is opened with
stream_socket_client, the callback method defined with the notification
parameters of stream_context_set_params never get called.
And the current documentation is pointless regarding which wrapper actually
support the notifications.
As far as I can see ftp and http wrappers support it but tcp socket (or
even file://) don't.
Callback notification function is the way to perform efficient and advanced
monitoring on socket.
It should be invoked for the following events:
STREAM_NOTIFY_RESOLVE Yes
STREAM_NOTIFY_CONNECT Yes
STREAM_NOTIFY_AUTH_REQUIRED No
STREAM_NOTIFY_MIME_TYPE_IS No
STREAM_NOTIFY_FILE_SIZE_IS No
STREAM_NOTIFY_REDIRECTED No
STREAM_NOTIFY_PROGRESS Yes but optional
STREAM_NOTIFY_COMPLETED Yes
STREAM_NOTIFY_FAILURE Oh Yes
STREAM_NOTIFY_AUTH_RESULT No
STREAM_NOTIFY_SEVERITY_INFO Yes
STREAM_NOTIFY_SEVERITY_WARN Yes
STREAM_NOTIFY_SEVERITY_ERR Yes
Test script:
---
?php
// define our callback method
function snc() { var_dump(func_get_args()); }
$ctx= stream_context_create();
stream_context_set_params($ctx, array(notification = snc));
$uri= htttp://www.example.net;
$socket = stream_socket_client($uri, $errno, $errstr, 0,
STREAM_CLIENT_CONNECT, $ctx); // snc should already have been called here
for at least connection and resolv.
$line =fgets($socket); // get one line.
fclose($socket); // close the connection.
// Run the above lines and snc() never gets called.
Expected result:
1. Update documentation to let developers know the current state of the
callback support
2. Have the callback method invoked when using socket streams for the
following events (where applicable).
Actual result:
--
The scn method never gets called.
--
Edit bug report at http://bugs.php.net/bug.php?id=52811edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52811r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52811r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52811r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52811r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52811r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52811r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52811r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52811r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52811r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52811r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52811r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52811r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52811r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52811r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52811r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52811r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52811r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52811r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52811r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52811r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52811r=mysqlcfg
#39138 [Com]: LOCK_NB for flock() does not work
ID: 39138 Comment by: sp at vovochka dot org dot ua Reported By: php at koterov dot ru Status: No Feedback Bug Type: Filesystem function related Operating System: Windows, Linux PHP Version: 5.1.6 New Comment: Guys! Are you going to fix this bug. It is more than 3 years old! It is reproducable on NTFS. Previous Comments: [2007-05-28 10:50:44] bugreporter at sigproc dot de Hi, problem might be just due to unclear documentation on how to apply LOCK_NB. The current flock docu says one should add LOCK_NB to $operation (i.e. to the second parameter of the function). A comment on the docu page wants to assure us that neither of the following will work (administrator at proxy-list dot org, 30-Apr-2007 08:30) ?php flock($fp, LOCK_EX and LOCK_SH); flock($fp, LOCK_EX or LOCK_SH); flock($fp, LOCK_EX + LOCK_SH); ? (Rather separate flock calls should be used.) So question to the PHP devs: what is the right way to do it? Cheers [2006-10-22 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, 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. [2006-10-14 13:09:50] tony2...@php.net Where can I see the results? (as I'm unable to reproduce it locally) [2006-10-13 19:06:49] php at koterov dot ru I cannot try snapshot on Linux - I have no machine for experiments. And you said that Linux has no problem in new version. Now we are talking about Windows only. [2006-10-13 14:20:28] tony2...@php.net Wait, so did you try the snapshot on Linux? Or are you talking only of Windows now? 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/39138 -- Edit this bug report at http://bugs.php.net/?id=39138edit=1
#22297 [Fbk-Opn]: Timeout when reading file from URL
ID: 22297 User updated by: sp at m-me dot dk Reported By: sp at m-me dot dk -Status: Feedback +Status: Open Bug Type: Apache2 related Operating System: Windows PHP Version: 4.3.2-dev New Comment: Back... Sorry for the delay :) I have looked around to find out how to setup Apache 2.x to use PHP. I do think that I do it right. Take a look at: http://dk.php.net/manual/en/install.apache2.php#install.apache2.windows But let me know if I am wrong. Anyway. I saw that a new version of Apache was released (v2.0.44) and tried this one - And it actually seems to work! I will just try this on one other installation tomorrow before I will say that upgrading Apache solves the problem. So don't close it yet. Previous Comments: [2003-02-23 05:13:04] [EMAIL PROTECTED] Please check this page: http://www.experts-exchange.com/Web/Web_Servers/Apache/Q_20396513.html I think this is just configuration error..you're mixing the module configuration with CGI configuration.. [2003-02-23 05:06:20] [EMAIL PROTECTED] oops..forget my last comment, wrong bug report. [2003-02-23 05:05:45] [EMAIL PROTECTED] And what about php.ini? Have you set the settings required for IIS in it? [2003-02-21 09:39:59] sp at m-me dot dk CGI binary I have added this to my httpd.conf: -- DirectoryIndex index.html index.html.var index.php ScriptAlias /php/ c:/php/ AddType application/x-httpd-php .php AddType application/x-httpd-php-source .phps Action application/x-httpd-php /php/php.exe [2003-02-21 09:09:01] [EMAIL PROTECTED] oops..forgot to ask: Are you using the CGI binary or the apache2 module? 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/22297 -- Edit this bug report at http://bugs.php.net/?id=22297edit=1
#22297 [Fbk-Opn]: Timeout when reading file from URL
ID: 22297
User updated by: sp at m-me dot dk
Reported By: sp at m-me dot dk
-Status: Feedback
+Status: Open
Bug Type: Filesystem function related
Operating System: Windows
PHP Version: 4.3.2-dev
New Comment:
Using 127.0.0.1 instead of localhost had no effect. The script still
took 2 * default_socket_timeout seconds.
The var_dump(gethostbynamel(localhost)); returned (with no delay):
array(1) {
[0]=
string(9) 127.0.0.1
}
Previous Comments:
[2003-02-21 05:13:21] [EMAIL PROTECTED]
Could you also paste the output of this script:
?php
var_dump(gethostbynamel(localhost));
?
[2003-02-21 05:00:06] [EMAIL PROTECTED]
Can you try using 127.0.0.1 instead of localhost in your script?
If that fixes it for you, I will add equivalent code into the PHP core
itself (when running under windows).
[2003-02-20 19:31:47] sp at m-me dot dk
[EMAIL PROTECTED] writes:
Your system has determined two alternative addresses to attempt to
contact for localhost and it attempts each alternative for
default_socket_timeout in seconds.
I'm not into how the file() function tries to read an URL, but after
what [EMAIL PROTECTED] writes it seems that it tries a couple of different
methods for reading the URL if the previous ones does not work. For me
it looks like the first 2 does not work, but the 3th does.
If that is right it then makes sense that the max_execution_time has
to be larger than 2 * default_socket_timeout (because the first two
tries have to time out fist)..
[2003-02-20 19:20:47] sp at m-me dot dk
I did a little test to try to find out when the script fails. It looks
like the script fails everytime the max_execution_time is smaller
than 2 * default_socket_timeout.
max_execution_time default_socket_timeout output
--
60 10 no error
25 10 no error
22 10 no error
21 10 no error
20 10 error
15 10 error
10 10 error
5 10 error
(when I write no error the script still runs for 2 *
default_socket_timeout seconds though)
[2003-02-20 19:02:57] sp at m-me dot dk
The script supplied gives the right output, but still takes
default_socket_timeout * 2 seconds. I found that if I removed the
first line set_time_limit(600); the script faild again - Still I
could not get rid of the long timeout.
The output from the code was:
--
array(1) {
[0]=
string(6) foobar
}
array(9) {
[0]=
string(15) HTTP/1.1 200 OK
[1]=
string(35) Date: Fri, 21 Feb 2003 00:43:31 GMT
[2]=
string(29) Server: Apache/2.0.43 (Win32)
[3]=
string(44) Last-Modified: Tue, 18 Feb 2003 15:48:22 GMT
[4]=
string(23) ETag: 37a6-6-d5528ab3
[5]=
string(20) Accept-Ranges: bytes
[6]=
string(17) Content-Length: 6
[7]=
string(17) Connection: close
[8]=
string(44) Content-Type: text/plain; charset=ISO-8859-1
}
--
The output from the curl command (had to install Cygwin) was:
--
$ curl -i http://localhost/test/readfile/test.txt
HTTP/1.1 200 OK
Date: Fri, 21 Feb 2003 00:41:16 GMT
Server: Apache/2.0.43 (Win32)
Last-Modified: Tue, 18 Feb 2003 15:48:22 GMT
ETag: 37a6-6-d5528ab3
Accept-Ranges: bytes
Content-Length: 6
Content-Type: text/plain; charset=ISO-8859-1
foobar
--
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/22297
--
Edit this bug report at http://bugs.php.net/?id=22297edit=1
#22297 [Fbk-Opn]: Timeout when reading file from URL
ID: 22297
User updated by: sp at m-me dot dk
Reported By: sp at m-me dot dk
-Status: Feedback
+Status: Open
Bug Type: Filesystem function related
Operating System: Windows
PHP Version: 4.3.2-dev
New Comment:
I have tried 3 different addresses:
localhost
127.0.0.1
www.the-real-domain.com
...all with the same result. Further more I have tried this on 3
different machines (two Windows XP and one Windows 2000 - some even on
different networks).
The thing with Apache 1.3.x vs. Apache 2.x have crossed my mind as I
wrote earlier. I'll try to install Apache 1.3.x and return with the
results here asap.
Previous Comments:
[2003-02-21 07:54:44] [EMAIL PROTECTED]
Are you sure that you have your DNS (client) settings correct on the
windows machine(s)?
eg: multiple entries for localhost in the hosts file, or multiple
domains to auto-search when a suffix is missing configured in your DNS
server (if you have one)?
It doesn't make sense for PHP to attempt multiple addresses when it can
only detect a single address.
Is there any chance you can try apache 1.3.x on one of the windows
servers to see if that has an effect?
[2003-02-21 06:26:39] sp at m-me dot dk
Using 127.0.0.1 instead of localhost had no effect. The script still
took 2 * default_socket_timeout seconds.
The var_dump(gethostbynamel(localhost)); returned (with no delay):
array(1) {
[0]=
string(9) 127.0.0.1
}
[2003-02-21 05:13:21] [EMAIL PROTECTED]
Could you also paste the output of this script:
?php
var_dump(gethostbynamel(localhost));
?
[2003-02-21 05:00:06] [EMAIL PROTECTED]
Can you try using 127.0.0.1 instead of localhost in your script?
If that fixes it for you, I will add equivalent code into the PHP core
itself (when running under windows).
[2003-02-20 19:31:47] sp at m-me dot dk
[EMAIL PROTECTED] writes:
Your system has determined two alternative addresses to attempt to
contact for localhost and it attempts each alternative for
default_socket_timeout in seconds.
I'm not into how the file() function tries to read an URL, but after
what [EMAIL PROTECTED] writes it seems that it tries a couple of different
methods for reading the URL if the previous ones does not work. For me
it looks like the first 2 does not work, but the 3th does.
If that is right it then makes sense that the max_execution_time has
to be larger than 2 * default_socket_timeout (because the first two
tries have to time out fist)..
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/22297
--
Edit this bug report at http://bugs.php.net/?id=22297edit=1
#22297 [Opn]: Timeout when reading file from URL
ID: 22297
User updated by: sp at m-me dot dk
Reported By: sp at m-me dot dk
Status: Open
Bug Type: Filesystem function related
Operating System: Windows
PHP Version: 4.3.2-dev
New Comment:
Hi... I'm back :)
I tried the script on a Windows XP sp1 running Apache 1.3.43 and PHP
4.3.2-dev. There was no errors at all. So it has something to do with
Apache 2.x and PHP.
Previous Comments:
[2003-02-21 08:10:17] sp at m-me dot dk
I have tried 3 different addresses:
localhost
127.0.0.1
www.the-real-domain.com
...all with the same result. Further more I have tried this on 3
different machines (two Windows XP and one Windows 2000 - some even on
different networks).
The thing with Apache 1.3.x vs. Apache 2.x have crossed my mind as I
wrote earlier. I'll try to install Apache 1.3.x and return with the
results here asap.
[2003-02-21 07:54:44] [EMAIL PROTECTED]
Are you sure that you have your DNS (client) settings correct on the
windows machine(s)?
eg: multiple entries for localhost in the hosts file, or multiple
domains to auto-search when a suffix is missing configured in your DNS
server (if you have one)?
It doesn't make sense for PHP to attempt multiple addresses when it can
only detect a single address.
Is there any chance you can try apache 1.3.x on one of the windows
servers to see if that has an effect?
[2003-02-21 06:26:39] sp at m-me dot dk
Using 127.0.0.1 instead of localhost had no effect. The script still
took 2 * default_socket_timeout seconds.
The var_dump(gethostbynamel(localhost)); returned (with no delay):
array(1) {
[0]=
string(9) 127.0.0.1
}
[2003-02-21 05:13:21] [EMAIL PROTECTED]
Could you also paste the output of this script:
?php
var_dump(gethostbynamel(localhost));
?
[2003-02-21 05:00:06] [EMAIL PROTECTED]
Can you try using 127.0.0.1 instead of localhost in your script?
If that fixes it for you, I will add equivalent code into the PHP core
itself (when running under windows).
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/22297
--
Edit this bug report at http://bugs.php.net/?id=22297edit=1
#22297 [Fbk-Opn]: Timeout when reading file from URL
ID: 22297 User updated by: sp at m-me dot dk Reported By: sp at m-me dot dk -Status: Feedback +Status: Open Bug Type: Apache2 related Operating System: Windows PHP Version: 4.3.2-dev New Comment: CGI binary I have added this to my httpd.conf: -- DirectoryIndex index.html index.html.var index.php ScriptAlias /php/ c:/php/ AddType application/x-httpd-php .php AddType application/x-httpd-php-source .phps Action application/x-httpd-php /php/php.exe Previous Comments: [2003-02-21 09:09:01] [EMAIL PROTECTED] oops..forgot to ask: Are you using the CGI binary or the apache2 module? [2003-02-21 09:07:38] [EMAIL PROTECTED] Reclassified tas Apache2 related bug. [2003-02-21 08:32:01] sp at m-me dot dk Hi... I'm back :) I tried the script on a Windows XP sp1 running Apache 1.3.43 and PHP 4.3.2-dev. There was no errors at all. So it has something to do with Apache 2.x and PHP. [2003-02-21 08:10:17] sp at m-me dot dk I have tried 3 different addresses: localhost 127.0.0.1 www.the-real-domain.com ...all with the same result. Further more I have tried this on 3 different machines (two Windows XP and one Windows 2000 - some even on different networks). The thing with Apache 1.3.x vs. Apache 2.x have crossed my mind as I wrote earlier. I'll try to install Apache 1.3.x and return with the results here asap. [2003-02-21 07:54:44] [EMAIL PROTECTED] Are you sure that you have your DNS (client) settings correct on the windows machine(s)? eg: multiple entries for localhost in the hosts file, or multiple domains to auto-search when a suffix is missing configured in your DNS server (if you have one)? It doesn't make sense for PHP to attempt multiple addresses when it can only detect a single address. Is there any chance you can try apache 1.3.x on one of the windows servers to see if that has an effect? 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/22297 -- Edit this bug report at http://bugs.php.net/?id=22297edit=1
#22297 [Fbk-Opn]: Timeout when reading file from URL
ID: 22297 User updated by: sp at m-me dot dk Reported By: sp at m-me dot dk -Status: Feedback +Status: Open Bug Type: Filesystem function related Operating System: Windows PHP Version: 4.3.2-dev New Comment: When setting default_socket_timeout to... 5 the script runs in 10 10 the script runs in 20 60 the script runs in 120 With all of the above the script still ends up showing: Fatal error: Maximum execution time of 5 seconds exceeded in C:\wwwroot\test\readfile\read.php on line 3 ...when trying to read a file from a URL. Previous Comments: [2003-02-19 19:03:34] [EMAIL PROTECTED] Forget getting newer snapshot, just try adjusting that php.ini directive.. [2003-02-19 19:02:48] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip And check that your php.ini has this setting: default_socket_timeout = 60 If not, add it and try again.. [2003-02-19 17:29:03] sp at m-me dot dk I've tried the latest stable windows release (4.3.2-dev) on System 1, but with the same results. By the way. I must have been a little tired when writing about the symtoms from system 1 and 2. They are instead like this: No matter what the maximum PHP execution time is set to, the script is running in 2 minutes before it stops and writes: Fatal error: Maximum execution time of 5 seconds exceeded in C:\wwwroot\test\readfile\read.php on line 3 In this example the max PHP execution time is set to 5 sec, but first after 2 min the script stops. The Apache timeout is set to 300 sec (5 min). For some reason I found that it is not always that the webservers error log contain any information about the event. But when it does it looks like this: [Wed Feb 19 16:14:31 2003] [error] [client 127.0.0.1] Premature end of script headers: php.exe With Apache 2.0.43 and Windows I've tested this on the following PHP versions: 4.2.3 No output to the browser, Internal Server Error 4.3.0 Error message outputted to browser after 2 min 4.3.1 Error message outputted to browser after 2 min 4.3.2-dev Error message outputted to browser after 2 min /watson [2003-02-19 09:13:25] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip There was a fix for a problem in the HTTP reader that went into CVS last night; please try a stable snapshot and let us know if this problem is fixed for you. [2003-02-19 09:10:04] sp at m-me dot dk When using the function file() or file_get_contents() added in PHP 4.3.0 I have a problem when I try to read a URL instead of reading directly from the filesystem. This works fine: file(test.txt); This creates an Internal Server Error the webserver: file(http://localhost/test.txt;); I've testet this on 3 different systems: System 1: Windows XP Pro sp1 Apache 2.0.43 PHP 4.3.1 System 2: Windows 2000 Server (build 5002195) sp3 Apache 2.0.43 PHP 4.3.0 System 3: Linux 2.4.20 Apache 1.3.27 PHP 4.3.1 This is what happend on the 3 systems: System 1: The browser is loading for about 5 minutes (more than the the maximum PHP execution time!?) then displays an Internal Server Error and writes this in the webserver error log: [Wed Feb 19 14:54:40 2003] [error] [client 127.0.0.1] Premature end of script headers: php.exe, referer: http://localhost/test/readfile/ System 2: The browser is loading for 30 sec. (the maximum PHP execution time) and then displays this in the browser: Fatal error: Maximum execution time of 30 seconds exceeded in C:\data\htdocs\fil1.php on line 3 and this in the webserver error log: [Wed Feb 19 15:32:41 2003] [error] [client 127.0.0.1] Premature end of script headers: php.exe, referer: http://localhost/ System 3: On the this system (the Linux system) both examples worked without any errors. Besides the operating system the biggest difference between the other systems and this one is the Apache version. Could it be Apache 2.x vs. PHP 4.3.x that was the problem? /watson -- Edit this bug report at http
#22297 [Fbk-Opn]: Timeout when reading file from URL
ID: 22297
User updated by: sp at m-me dot dk
Reported By: sp at m-me dot dk
-Status: Feedback
+Status: Open
Bug Type: Filesystem function related
Operating System: Windows
PHP Version: 4.3.2-dev
New Comment:
The script supplied gives the right output, but still takes
default_socket_timeout * 2 seconds. I found that if I removed the
first line set_time_limit(600); the script faild again - Still I
could not get rid of the long timeout.
The output from the code was:
--
array(1) {
[0]=
string(6) foobar
}
array(9) {
[0]=
string(15) HTTP/1.1 200 OK
[1]=
string(35) Date: Fri, 21 Feb 2003 00:43:31 GMT
[2]=
string(29) Server: Apache/2.0.43 (Win32)
[3]=
string(44) Last-Modified: Tue, 18 Feb 2003 15:48:22 GMT
[4]=
string(23) ETag: 37a6-6-d5528ab3
[5]=
string(20) Accept-Ranges: bytes
[6]=
string(17) Content-Length: 6
[7]=
string(17) Connection: close
[8]=
string(44) Content-Type: text/plain; charset=ISO-8859-1
}
--
The output from the curl command (had to install Cygwin) was:
--
$ curl -i http://localhost/test/readfile/test.txt
HTTP/1.1 200 OK
Date: Fri, 21 Feb 2003 00:41:16 GMT
Server: Apache/2.0.43 (Win32)
Last-Modified: Tue, 18 Feb 2003 15:48:22 GMT
ETag: 37a6-6-d5528ab3
Accept-Ranges: bytes
Content-Length: 6
Content-Type: text/plain; charset=ISO-8859-1
foobar
--
Previous Comments:
[2003-02-20 14:39:52] [EMAIL PROTECTED]
Your system has determined two alternative addresses to attempt to
contact for localhost and it attempts each alternative for
default_socket_timeout in seconds.
For some reason it is not connecting successfully.
Please try the following script:
?php
set_time_limit(600);
ini_set('default_socket_timeout', 5);
$x = file(http://localhost/test.txt;);
var_dump($x);
var_dump($http_response_header);
?
and report back here.
It would also help if you could try fetching the same url using:
curl -i http://localhost/test.txt
and paste the output here.
[2003-02-20 06:42:29] sp at m-me dot dk
When setting default_socket_timeout to...
5 the script runs in 10
10 the script runs in 20
60 the script runs in 120
With all of the above the script still ends up showing:
Fatal error: Maximum execution time of 5 seconds exceeded in
C:\wwwroot\test\readfile\read.php on line 3
...when trying to read a file from a URL.
[2003-02-19 19:03:34] [EMAIL PROTECTED]
Forget getting newer snapshot, just try adjusting that
php.ini directive..
[2003-02-19 19:02:48] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
And check that your php.ini has this setting:
default_socket_timeout = 60
If not, add it and try again..
[2003-02-19 17:29:03] sp at m-me dot dk
I've tried the latest stable windows release (4.3.2-dev) on System 1,
but with the same results.
By the way. I must have been a little tired when writing about the
symtoms from system 1 and 2. They are instead like this:
No matter what the maximum PHP execution time is set to, the script is
running in 2 minutes before it stops and writes:
Fatal error: Maximum execution time of 5 seconds exceeded in
C:\wwwroot\test\readfile\read.php on line 3
In this example the max PHP execution time is set to 5 sec, but first
after 2 min the script stops. The Apache timeout is set to 300 sec (5
min).
For some reason I found that it is not always that the webservers error
log contain any information about the event. But when it does it looks
like this:
[Wed Feb 19 16:14:31 2003] [error] [client 127.0.0.1] Premature end of
script headers: php.exe
With Apache 2.0.43 and Windows I've tested this on the following PHP
versions:
4.2.3 No output to the browser, Internal Server Error
4.3.0 Error message outputted to browser after 2 min
4.3.1 Error message outputted to browser after 2 min
4.3.2-dev Error message outputted to browser after 2 min
/watson
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/22297
--
Edit this bug report at http://bugs.php.net/?id=22297edit=1
#22297 [Opn]: Timeout when reading file from URL
ID: 22297
User updated by: sp at m-me dot dk
Reported By: sp at m-me dot dk
Status: Open
Bug Type: Filesystem function related
Operating System: Windows
PHP Version: 4.3.2-dev
New Comment:
I did a little test to try to find out when the script fails. It looks
like the script fails everytime the max_execution_time is smaller
than 2 * default_socket_timeout.
max_execution_time default_socket_timeout output
--
60 10 no error
25 10 no error
22 10 no error
21 10 no error
20 10 error
15 10 error
10 10 error
5 10 error
(when I write no error the script still runs for 2 *
default_socket_timeout seconds though)
Previous Comments:
[2003-02-20 19:02:57] sp at m-me dot dk
The script supplied gives the right output, but still takes
default_socket_timeout * 2 seconds. I found that if I removed the
first line set_time_limit(600); the script faild again - Still I
could not get rid of the long timeout.
The output from the code was:
--
array(1) {
[0]=
string(6) foobar
}
array(9) {
[0]=
string(15) HTTP/1.1 200 OK
[1]=
string(35) Date: Fri, 21 Feb 2003 00:43:31 GMT
[2]=
string(29) Server: Apache/2.0.43 (Win32)
[3]=
string(44) Last-Modified: Tue, 18 Feb 2003 15:48:22 GMT
[4]=
string(23) ETag: 37a6-6-d5528ab3
[5]=
string(20) Accept-Ranges: bytes
[6]=
string(17) Content-Length: 6
[7]=
string(17) Connection: close
[8]=
string(44) Content-Type: text/plain; charset=ISO-8859-1
}
--
The output from the curl command (had to install Cygwin) was:
--
$ curl -i http://localhost/test/readfile/test.txt
HTTP/1.1 200 OK
Date: Fri, 21 Feb 2003 00:41:16 GMT
Server: Apache/2.0.43 (Win32)
Last-Modified: Tue, 18 Feb 2003 15:48:22 GMT
ETag: 37a6-6-d5528ab3
Accept-Ranges: bytes
Content-Length: 6
Content-Type: text/plain; charset=ISO-8859-1
foobar
--
[2003-02-20 14:39:52] [EMAIL PROTECTED]
Your system has determined two alternative addresses to attempt to
contact for localhost and it attempts each alternative for
default_socket_timeout in seconds.
For some reason it is not connecting successfully.
Please try the following script:
?php
set_time_limit(600);
ini_set('default_socket_timeout', 5);
$x = file(http://localhost/test.txt;);
var_dump($x);
var_dump($http_response_header);
?
and report back here.
It would also help if you could try fetching the same url using:
curl -i http://localhost/test.txt
and paste the output here.
[2003-02-20 06:42:29] sp at m-me dot dk
When setting default_socket_timeout to...
5 the script runs in 10
10 the script runs in 20
60 the script runs in 120
With all of the above the script still ends up showing:
Fatal error: Maximum execution time of 5 seconds exceeded in
C:\wwwroot\test\readfile\read.php on line 3
...when trying to read a file from a URL.
[2003-02-19 19:03:34] [EMAIL PROTECTED]
Forget getting newer snapshot, just try adjusting that
php.ini directive..
[2003-02-19 19:02:48] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
And check that your php.ini has this setting:
default_socket_timeout = 60
If not, add it and try again..
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/22297
--
Edit this bug report at http://bugs.php.net/?id=22297edit=1
#22297 [Opn]: Timeout when reading file from URL
ID: 22297
User updated by: sp at m-me dot dk
Reported By: sp at m-me dot dk
Status: Open
Bug Type: Filesystem function related
Operating System: Windows
PHP Version: 4.3.2-dev
New Comment:
[EMAIL PROTECTED] writes:
Your system has determined two alternative addresses to attempt to
contact for localhost and it attempts each alternative for
default_socket_timeout in seconds.
I'm not into how the file() function tries to read an URL, but after
what [EMAIL PROTECTED] writes it seems that it tries a couple of different
methods for reading the URL if the previous ones does not work. For me
it looks like the first 2 does not work, but the 3th does.
If that is right it then makes sense that the max_execution_time has
to be larger than 2 * default_socket_timeout (because the first two
tries have to time out fist)..
Previous Comments:
[2003-02-20 19:20:47] sp at m-me dot dk
I did a little test to try to find out when the script fails. It looks
like the script fails everytime the max_execution_time is smaller
than 2 * default_socket_timeout.
max_execution_time default_socket_timeout output
--
60 10 no error
25 10 no error
22 10 no error
21 10 no error
20 10 error
15 10 error
10 10 error
5 10 error
(when I write no error the script still runs for 2 *
default_socket_timeout seconds though)
[2003-02-20 19:02:57] sp at m-me dot dk
The script supplied gives the right output, but still takes
default_socket_timeout * 2 seconds. I found that if I removed the
first line set_time_limit(600); the script faild again - Still I
could not get rid of the long timeout.
The output from the code was:
--
array(1) {
[0]=
string(6) foobar
}
array(9) {
[0]=
string(15) HTTP/1.1 200 OK
[1]=
string(35) Date: Fri, 21 Feb 2003 00:43:31 GMT
[2]=
string(29) Server: Apache/2.0.43 (Win32)
[3]=
string(44) Last-Modified: Tue, 18 Feb 2003 15:48:22 GMT
[4]=
string(23) ETag: 37a6-6-d5528ab3
[5]=
string(20) Accept-Ranges: bytes
[6]=
string(17) Content-Length: 6
[7]=
string(17) Connection: close
[8]=
string(44) Content-Type: text/plain; charset=ISO-8859-1
}
--
The output from the curl command (had to install Cygwin) was:
--
$ curl -i http://localhost/test/readfile/test.txt
HTTP/1.1 200 OK
Date: Fri, 21 Feb 2003 00:41:16 GMT
Server: Apache/2.0.43 (Win32)
Last-Modified: Tue, 18 Feb 2003 15:48:22 GMT
ETag: 37a6-6-d5528ab3
Accept-Ranges: bytes
Content-Length: 6
Content-Type: text/plain; charset=ISO-8859-1
foobar
--
[2003-02-20 14:39:52] [EMAIL PROTECTED]
Your system has determined two alternative addresses to attempt to
contact for localhost and it attempts each alternative for
default_socket_timeout in seconds.
For some reason it is not connecting successfully.
Please try the following script:
?php
set_time_limit(600);
ini_set('default_socket_timeout', 5);
$x = file(http://localhost/test.txt;);
var_dump($x);
var_dump($http_response_header);
?
and report back here.
It would also help if you could try fetching the same url using:
curl -i http://localhost/test.txt
and paste the output here.
[2003-02-20 06:42:29] sp at m-me dot dk
When setting default_socket_timeout to...
5 the script runs in 10
10 the script runs in 20
60 the script runs in 120
With all of the above the script still ends up showing:
Fatal error: Maximum execution time of 5 seconds exceeded in
C:\wwwroot\test\readfile\read.php on line 3
...when trying to read a file from a URL.
[2003-02-19 19:03:34] [EMAIL PROTECTED]
Forget getting newer snapshot, just try adjusting that
php.ini directive..
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/22297
--
Edit this bug report at http://bugs.php.net/?id=22297edit=1
#22297 [NEW]: Timeout when reading file from URL
From: sp at m-me dot dk Operating system: Windows PHP version: 4.3.1 PHP Bug Type: Filesystem function related Bug description: Timeout when reading file from URL When using the function file() or file_get_contents() added in PHP 4.3.0 I have a problem when I try to read a URL instead of reading directly from the filesystem. This works fine: file(test.txt); This creates an Internal Server Error the webserver: file(http://localhost/test.txt;); I've testet this on 3 different systems: System 1: Windows XP Pro sp1 Apache 2.0.43 PHP 4.3.1 System 2: Windows 2000 Server (build 5002195) sp3 Apache 2.0.43 PHP 4.3.0 System 3: Linux 2.4.20 Apache 1.3.27 PHP 4.3.1 This is what happend on the 3 systems: System 1: The browser is loading for about 5 minutes (more than the the maximum PHP execution time!?) then displays an Internal Server Error and writes this in the webserver error log: [Wed Feb 19 14:54:40 2003] [error] [client 127.0.0.1] Premature end of script headers: php.exe, referer: http://localhost/test/readfile/ System 2: The browser is loading for 30 sec. (the maximum PHP execution time) and then displays this in the browser: Fatal error: Maximum execution time of 30 seconds exceeded in C:\data\htdocs\fil1.php on line 3 and this in the webserver error log: [Wed Feb 19 15:32:41 2003] [error] [client 127.0.0.1] Premature end of script headers: php.exe, referer: http://localhost/ System 3: On the this system (the Linux system) both examples worked without any errors. Besides the operating system the biggest difference between the other systems and this one is the Apache version. Could it be Apache 2.x vs. PHP 4.3.x that was the problem? /watson -- Edit bug report at http://bugs.php.net/?id=22297edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=22297r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=22297r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=22297r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=22297r=needtrace Try newer version: http://bugs.php.net/fix.php?id=22297r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=22297r=support Expected behavior: http://bugs.php.net/fix.php?id=22297r=notwrong Not enough info:http://bugs.php.net/fix.php?id=22297r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=22297r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=22297r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22297r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=22297r=dst IIS Stability: http://bugs.php.net/fix.php?id=22297r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=22297r=gnused
#22297 [Fbk-Opn]: Timeout when reading file from URL
ID: 22297 User updated by: sp at m-me dot dk Reported By: sp at m-me dot dk -Status: Feedback +Status: Open Bug Type: Filesystem function related Operating System: Windows PHP Version: 4.3.1 New Comment: I've tried the latest stable windows release (4.3.2-dev) on System 1, but with the same results. By the way. I must have been a little tired when writing about the symtoms from system 1 and 2. They are instead like this: No matter what the maximum PHP execution time is set to, the script is running in 2 minutes before it stops and writes: Fatal error: Maximum execution time of 5 seconds exceeded in C:\wwwroot\test\readfile\read.php on line 3 In this example the max PHP execution time is set to 5 sec, but first after 2 min the script stops. The Apache timeout is set to 300 sec (5 min). For some reason I found that it is not always that the webservers error log contain any information about the event. But when it does it looks like this: [Wed Feb 19 16:14:31 2003] [error] [client 127.0.0.1] Premature end of script headers: php.exe With Apache 2.0.43 and Windows I've tested this on the following PHP versions: 4.2.3 No output to the browser, Internal Server Error 4.3.0 Error message outputted to browser after 2 min 4.3.1 Error message outputted to browser after 2 min 4.3.2-dev Error message outputted to browser after 2 min /watson Previous Comments: [2003-02-19 09:13:25] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip There was a fix for a problem in the HTTP reader that went into CVS last night; please try a stable snapshot and let us know if this problem is fixed for you. [2003-02-19 09:10:04] sp at m-me dot dk When using the function file() or file_get_contents() added in PHP 4.3.0 I have a problem when I try to read a URL instead of reading directly from the filesystem. This works fine: file(test.txt); This creates an Internal Server Error the webserver: file(http://localhost/test.txt;); I've testet this on 3 different systems: System 1: Windows XP Pro sp1 Apache 2.0.43 PHP 4.3.1 System 2: Windows 2000 Server (build 5002195) sp3 Apache 2.0.43 PHP 4.3.0 System 3: Linux 2.4.20 Apache 1.3.27 PHP 4.3.1 This is what happend on the 3 systems: System 1: The browser is loading for about 5 minutes (more than the the maximum PHP execution time!?) then displays an Internal Server Error and writes this in the webserver error log: [Wed Feb 19 14:54:40 2003] [error] [client 127.0.0.1] Premature end of script headers: php.exe, referer: http://localhost/test/readfile/ System 2: The browser is loading for 30 sec. (the maximum PHP execution time) and then displays this in the browser: Fatal error: Maximum execution time of 30 seconds exceeded in C:\data\htdocs\fil1.php on line 3 and this in the webserver error log: [Wed Feb 19 15:32:41 2003] [error] [client 127.0.0.1] Premature end of script headers: php.exe, referer: http://localhost/ System 3: On the this system (the Linux system) both examples worked without any errors. Besides the operating system the biggest difference between the other systems and this one is the Apache version. Could it be Apache 2.x vs. PHP 4.3.x that was the problem? /watson -- Edit this bug report at http://bugs.php.net/?id=22297edit=1
#20744 [NEW]: Browser output is not XHTML compliant
From: [EMAIL PROTECTED] Operating system: All PHP version: 4.2.3 PHP Bug Type: Session related Bug description: Browser output is not XHTML compliant I constructed a test site to show my point: http://www.wopr.dk/misc/formproblem.php If you click at the W3C XHTML 1.1 picture you will see that the site contains one error: document type does not allow element 'input' here The input element the validator refers to is this one: input type=hidden name=PHPSESSID value=d509686534734e1c5b1ac66ef2a54c2e / The problem is that according to the XHTML standard all input elements should be contained inside a block level element (like in my case a div element). The session engine in PHP puts the session ID tag just after the opening form element. Instead it should look for the first input, textarea etc. element inside the form and put the hidden session input element just before that. Of cause action also has to be taken if no such element is contained inside the form. Look at this link for another description of the problem (not PHP related): http://lists.w3.org/Archives/Public/www-validator/2001Sep/0114.html /watson -- Edit bug report at http://bugs.php.net/?id=20744edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20744r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20744r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20744r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20744r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20744r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20744r=support Expected behavior: http://bugs.php.net/fix.php?id=20744r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20744r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20744r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20744r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20744r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20744r=dst IIS Stability: http://bugs.php.net/fix.php?id=20744r=isapi
Bug #16790: Installation instructions is outdated
From: [EMAIL PROTECTED] Operating system: Windows PHP version: 4.2.0 PHP Bug Type: Documentation problem Bug description: Installation instructions is outdated I tried to install the new PHP 4.2 on my Windows 2000 server and found several things in the installation manual that where out of date. The manual I refer to in this report is the following: http://www.php.net/manual/en/install-windows.php When I use the zip file (not the installer) downloaded from php.net I run into these problems: - The manual does not say anything about where to get the php.exe file. The only php.exe file in the zip package is located in the sapi directory, and I do therefore not believe that it is this one I should use. - There is a new directory called experimental. It seems to hold all the experimental extensions (in prev. versions I believe that they where located in the extensions directory like all the others). This should also be in the manual (i.e. tell the user to copy the experimental extensions wanted to the extensions directory or set the extension path to point to this directory also). - extensions/php_gd.dll does no longer exist. I guess it's now called extensions/php_gd2.dll. Both the php.ini file and the documentation lacks this information. I don't know if there are anything more then this, but it seems like this manual is from one of the PHP 4.0.? versions. /watson -- Edit bug report at http://bugs.php.net/?id=16790edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16790r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16790r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16790r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16790r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16790r=support Expected behavior: http://bugs.php.net/fix.php?id=16790r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16790r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16790r=submittedtwice
Bug #9852 Updated: Header redirect and db connection cause CGI misbehaved
ID: 9852
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: IIS related
Operating System: Windows 2000
PHP Version: 4.1.1
New Comment:
I tried to use both a MySQL and a MSSQL database server on the same
machine. When using the MySQL database there where no problem, and when
using the MSSQL database the problem was there.
So the problem seems to follow the combination of: IIS and MSSQL. I
have seen this error on all the PHP versions that I tried, and that is:
PHP 4.0.6, PHP 4.1.1 and PHP 4.1.2. I don't know if it's in any other
PHP versions besides that.
Previous Comments:
[2002-03-27 13:16:00] [EMAIL PROTECTED]
I can reproduce the problem with a simple bounce page (used for
measuring roundtrip times). With two active browser windows requesting
the same page, I see this error repeat (apparently at random) on one
out of 10-40 thousand requests.
This is with PHP 4.1.2 on Windows 2000 Professional w/ IIS 5 and all
the current updates from Windows Update.
bounce.php
--
html
head
titleBOUNCE/title
?php
list($usec, $sec) = explode( ,microtime());
$now = intval(1000*((float)$usec + (float)$sec));
$i = (isset($i) ? $i : 0);
$n = (isset($n) ? $n : 10);
$s = (isset($s) ? $s : 0);
$r = (isset($r) ? $r : 0);
?
?php if (0 == $i) { ?
meta http-equiv=Refresh content=0; URL=bounce.php?s=?= $s ?r=?=
$r ?i=1t=?= $now ?
?php } else if ($i $n) { ?
meta http-equiv=Refresh content=0; URL=bounce.php?s=?= $s ?r=?=
$r ?i=?= 1 + $i ?t=?= $t ?
?php } else { ?
?php
$e = $now - $t;
$r = $r + $n;
$s = $s + $e;
?
meta http-equiv=Refresh content=3; URL=bounce.php?s=?= $s ?r=?=
$r ?
?php } ?
/head
body
?php if ($i $n) { ?
h1BOUNCING/h1
?php } else { ?
h1BOUNCE/h1
table border=1
trthmilliseconds/ththrequests/th/tr
trtd?= intval($e/$n) ?/tdtd?= $n
?/tdtdlatest/td/tr
trtd?= intval($s/$r) ?/tdtd?= $r
?/tdtdcumulative/td/tr
/table
?php } ?
/body
/html
[2002-01-16 13:45:10] [EMAIL PROTECTED]
I have tried this with W2K server and php 4.1.1 and I am getting the
same problem. Its taken a while and in fact it was only when pointed at
this bug request that the answer was apparent. My problem was it wasnt
constant, it was intimittent, so, I assumed my server was crud. I
actually had rulled out a PHP bug coz it works fine on my portable
(W2K pro) every time, but under server .. no.. Although my server does
also farm hits to the company intranet so is generally under a lot more
stress than my portable.
I will continue further tests to see if doing includes takes the
problem away, as certainly, it seems the javascript of window.location=
seems to be fine. I assume PHP is being too fast for itself?
[2002-01-12 06:58:59] [EMAIL PROTECTED]
Can you try this with 4.1.1? There been alot of fixes for IIS in the
recent versions.
[2001-03-19 22:41:31] [EMAIL PROTECTED]
Under the category of You Can Never Have Too Much Information On A
Bug, here is my experience with the CGI App Misbehaved bug (related
bug reports: #8571 and #8744).
Bug report summary:
A PHP script that sends a 'Location' header directive and makes a
database connection causes IIS to intermittently return a 'Gateway
Error 502' when the client browser asks for the page specified in the
redirect. The address bar will correctly show the page that should
have loaded when the error is displayed, and pressing F5 (refresh) will
correctly load the page. Note that the error is (seemingly) completely
random, sometimes you get it, other times the script works correctly.
The error message text is:
-- Begin --
CGI Error
The specified CGI application misbehaved by not returning a complete
set of HTTP headers. The headers it did return are:
-- End --
This error depends on:
1) Using PHP in CGI mode (i.e. using php.exe, the ISAPI dll does not
seem to produce this error, although it has it's own problems).
2) A PHP script that connects to a database (tested both mssql_connect
and odbc_connect) *and* sends a 'Location:' header. If the script
redirects to something other than a .php file (i.e. .html or .pdf) or
does not connect to the database, the error will not occur.
3) A successful db connection. If the db connect call fails (due to
bad password, etc.), the redirect always works.
This error does *not* depend on:
1) A fully qualified 'Location' header. The following also fails:
header('Location: http://10.0.0.30/test/done.php');
2) The relative order of the header() and xxx_connect() calls in
'doit.php'. I wouldn't expect the order to affect the result, but I
checked it anyway.
Interesting note: While
Bug #9852 Updated: Header redirect and db connection cause CGI misbehaved
ID: 9852
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: IIS related
Operating System: Windows 2000
PHP Version: 4.1.1
New Comment:
It seems to be a timing problem (the PHP script outruns the IIS/MSSQL
or something). I came up with a simple solution to this by inserting a
short delay before every location header in my scripts.
I successfully made the workaround by using a function from a user
comment on the http://www.php.net/manual/en/function.usleep.php page
The function was:
--
function usleepWindows($usec) {
$start = gettimeofday();
do {
$stop = gettimeofday();
$timePassed = 100 * ($stop['sec'] - $start['sec'])
+ $stop['usec'] - $start['usec'];
}
while($timePassed $usec);
}
--
Every header call should then look like this:
--
usleepWindows(20);
header(Location: http://www.myserver.dk/mypage.php;);
exit;
--
/watson
Previous Comments:
[2002-04-22 16:36:05] [EMAIL PROTECTED]
I tried to use both a MySQL and a MSSQL database server on the same
machine. When using the MySQL database there where no problem, and when
using the MSSQL database the problem was there.
So the problem seems to follow the combination of: IIS and MSSQL. I
have seen this error on all the PHP versions that I tried, and that is:
PHP 4.0.6, PHP 4.1.1 and PHP 4.1.2. I don't know if it's in any other
PHP versions besides that.
[2002-03-27 13:16:00] [EMAIL PROTECTED]
I can reproduce the problem with a simple bounce page (used for
measuring roundtrip times). With two active browser windows requesting
the same page, I see this error repeat (apparently at random) on one
out of 10-40 thousand requests.
This is with PHP 4.1.2 on Windows 2000 Professional w/ IIS 5 and all
the current updates from Windows Update.
bounce.php
--
html
head
titleBOUNCE/title
?php
list($usec, $sec) = explode( ,microtime());
$now = intval(1000*((float)$usec + (float)$sec));
$i = (isset($i) ? $i : 0);
$n = (isset($n) ? $n : 10);
$s = (isset($s) ? $s : 0);
$r = (isset($r) ? $r : 0);
?
?php if (0 == $i) { ?
meta http-equiv=Refresh content=0; URL=bounce.php?s=?= $s ?r=?=
$r ?i=1t=?= $now ?
?php } else if ($i $n) { ?
meta http-equiv=Refresh content=0; URL=bounce.php?s=?= $s ?r=?=
$r ?i=?= 1 + $i ?t=?= $t ?
?php } else { ?
?php
$e = $now - $t;
$r = $r + $n;
$s = $s + $e;
?
meta http-equiv=Refresh content=3; URL=bounce.php?s=?= $s ?r=?=
$r ?
?php } ?
/head
body
?php if ($i $n) { ?
h1BOUNCING/h1
?php } else { ?
h1BOUNCE/h1
table border=1
trthmilliseconds/ththrequests/th/tr
trtd?= intval($e/$n) ?/tdtd?= $n
?/tdtdlatest/td/tr
trtd?= intval($s/$r) ?/tdtd?= $r
?/tdtdcumulative/td/tr
/table
?php } ?
/body
/html
[2002-01-16 13:45:10] [EMAIL PROTECTED]
I have tried this with W2K server and php 4.1.1 and I am getting the
same problem. Its taken a while and in fact it was only when pointed at
this bug request that the answer was apparent. My problem was it wasnt
constant, it was intimittent, so, I assumed my server was crud. I
actually had rulled out a PHP bug coz it works fine on my portable
(W2K pro) every time, but under server .. no.. Although my server does
also farm hits to the company intranet so is generally under a lot more
stress than my portable.
I will continue further tests to see if doing includes takes the
problem away, as certainly, it seems the javascript of window.location=
seems to be fine. I assume PHP is being too fast for itself?
[2002-01-12 06:58:59] [EMAIL PROTECTED]
Can you try this with 4.1.1? There been alot of fixes for IIS in the
recent versions.
[2001-03-19 22:41:31] [EMAIL PROTECTED]
Under the category of You Can Never Have Too Much Information On A
Bug, here is my experience with the CGI App Misbehaved bug (related
bug reports: #8571 and #8744).
Bug report summary:
A PHP script that sends a 'Location' header directive and makes a
database connection causes IIS to intermittently return a 'Gateway
Error 502' when the client browser asks for the page specified in the
redirect. The address bar will correctly show the page that should
have loaded when the error is displayed, and pressing F5 (refresh) will
correctly load the page. Note that the error is (seemingly) completely
random, sometimes you get it, other times the script works correctly.
The error message text is:
-- Begin --
CGI Error
The specified CGI application
Bug #14334 Updated: Bug in COM class
ID: 14334 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: COM related Operating System: Windows 2000 Professional PHP Version: 4.0.6 New Comment: I get the same error when I try to run the following code: - $af = new COM(AtheneFile.File); $af-SetDatabaseDetails(server, database, user, pass); $sti = $af-GetFile(295721, c:\\test.doc); - It is the last line that fails. This is my system data: PHP Version: 4.0.6 System: Windows NT 5.0 build 2195 Build Date: Jun 22 2001 Server API: CGI Virtual Directory Support: enabled Configuration File (php.ini) Path: C:\WINNT\php.ini ZEND_DEBUG: disabled Thread Safety: enabled Previous Comments: [2002-01-21 12:47:44] [EMAIL PROTECTED] I am having the same problem which is a bit stranger though. One time my call is correct while done in another place produces php_OLECHAR_to_char error message. Working: $pdflib = new COM(PDFlib_com.PDF); print $pdflib-get_parameter(version,0); Prints version string as expected. Not working: $pdflib = new COM(PDFlib_com.PDF); print $pdflib-set_parameter(fontwarning,1); print $pdflib-get_parameter(version,0); Produces error message for the get_parameter line and 0 (true !!! in php for PDFlib, -1 is false) for the fontwarning line. Also, to make it even stranger, at least to me: When I switch the line in the non-working example, I both get the version string and 0 for the fontwarning Is there something wrong about the way I connect to PDFLib ? HTH W. [2001-12-06 22:09:09] [EMAIL PROTECTED] If you mean php code, here goes: - $instance = new COM(WinampCOM.Application); $title = $instance-CurrentSongTitle; - The $title line will produce the error if run via the httpd, but not if pasted in the stdin of php.exe. The WinampCOM.Application com requires a winamp module, which can be found at http://www.adcock8.freeserve.co.uk/gen_com.zip If any more info is needed, please don't hesitate to ask. [2001-12-06 15:07:09] [EMAIL PROTECTED] If you mean php code, here goes: - $instance = new COM(WinampCOM.Application); $title = $instance-CurrentSongTitle; - The $title line will produce the error if run via the httpd, but not if pasted in the stdin of php.exe. The WinampCOM.Application com requires a winamp module, which can be found at http://www.adcock8.freeserve.co.uk/gen_com.zip If any more info is needed, please don't hesitate to ask. [2001-12-06 12:13:41] [EMAIL PROTECTED] please provide the shortest possible code that produces this error. [2001-12-04 02:55:21] [EMAIL PROTECTED] Warning: Error in php_OLECHAR_to_char() in g:\apache\test\index.php on line 65. This error is only returned when the script is run from the httpd. IIS, Apache, and Xitami, all return this error. When I use the script via pasting it to stdin on php.exe, it runs perfectly. The script returns no errors from the stdin. -- Edit this bug report at http://bugs.php.net/?id=14334edit=1
