ID: 21862
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: HTTP related
Operating System: Debian/libc-2.3.1,-2.2.5
PHP Version: 4.3.0
New Comment:
I think I found the problem, but I haven't yet tried to rebuild
a patched binary (and stupidly I don't have the 4.2.3 sources
anymore to grep if this was it),
it origins in the sapi/cgi/cgi_main.c:
//...
if (SG(sapi_headers).http_response_code != 200) {
int len;
if (rfc2616_headers) {
len = snprintf(buf, SAPI_CGI_MAX_HEADER_LENGTH,
"%s\r\n",
SG(sapi_headers).http_status_line);
} else {
len = sprintf(buf, "Status: %d\r\n",
SG(sapi_headers).http_response_code);
}
PHPWRITE_H(buf, len);
}
//...
(assuming this strange SG(whatever).whatever holds the correct
values).
The very first "if" in here says, the cgi headers headline is
only returned if the status code wasn't 200. And the problem is
that this is the most usual value.
Looks to me like another optimization of the CGI SAPI for
usage with only the Apache webserver. It is NOT necessary to
tune the CGI version for Apache, as almost all Apache users
compiler PHP using --with-apxs to get a mod_libphp version!!!
Ok, Apache usually assumes - nice like it always is - that the
Status Code is 200. But this wasn't always the case with Apache,
and this does not hold true if one uses the CGI binary as he
does with all the other common CGI interpreters (like perl,
bash, awk) -> so this is the bug, which breaks "nph-scripts.cgi"
for Apache and all other webservers.
So I would like to see a "cgi.apache_only" configure option rather
than all those stupid and heavily undocumented "cgi.fix_pathinfo",
"cgi.rfc2616_headers" and "cgi.force_redirect" options to make it
incompliant per default. *cry*
Previous Comments:
------------------------------------------------------------------------
[2003-01-24 12:30:40] [EMAIL PROTECTED]
I've (now) tried the
cgi.rfc2616_headers=1
(also using "on" and "On") but it didn't work anyway, and PHP
really did read the php.ini containing this setting.
I've tried the switch also with the 5.0.0-dev-lastweek but this
didn't show any changes too.
So these are the headers, if I use the "nph-script" to run Nanoweb
below Apache with all scripts running inside CGI-4.3.0:
(This is the "page info" from the w3m browser, as wget refused to work
due to the missing HTTP/1.x)
Date: Fri, 24 Jan 2003 17:49:27 GMT
Server: aEGiS_nanoweb/2.0.1.dev.20030113 (Linux; PHP/4.3.0)
X-Subserver-Wrapper: cgi-nanoweb/2.0.1-dev
Content-type: text/html; charset=iso-8859-1
X-Powered-By: PHP/4.3.0
Last-Modified: Fri, 24 Jan 2003 17:49:26 GMT
Expires: Sat, 25 Jan 2003 01:49:26 GMT
Connection: close
This is the same wrapper script running inside the CGI-4.2.3:
- the Powered-By is from another subsubscript (this really does not
matter for the problem)
- I've changed the "OK" to "OK-FROM-NANOWEB" to show that this really
comes from Nanoweb, as I feared Apache overwriting this field
HTTP/1.1 200 OK-FROM-NANOWEB
Date: Fri, 24 Jan 2003 18:05:43 GMT
Server: aEGiS_nanoweb/2.0.1.dev.20030113 (Linux; PHP/4.2.3)
X-Subserver-Wrapper: cgi-nanoweb/2.0.1-dev
Content-type: text/html; charset=iso-8859-1
X-Powered-By: PHP/4.3.0
Last-Modified: Fri, 24 Jan 2003 18:05:42 GMT
So if I don't use the "nph-" feature of apache, and run the script
as ordinary cgi (with 4.3.0) apache then will reparse the headers
and will gracefuly fix it by prepending a "HTTP/1.1 200 OK" on top
of it.
Because from inside the script (4.3.0) never such a CGI headline
reaches Apache the response will always contain "200 OK" regardless
of what the script says.
-
Here is the (shortened) output of phpinfo() inside the nph-script,
yes it is really the CGI version:
System => Linux yoco.erphesfurt.de 2.4.18 #17 Mit Dez 25 19:01:37 CET
2002 i586
Build Date => Jan 10 2003 00:34:31
Configure Command => './configure' '--prefix=/usr/local/'
'--sysconfdir=/etc/php4' '--with-config-file-path=/etc/php4'
'--disable-cli' '--with-cgi' '--without-pear' '--disable-magic-quotes'
'--with-zlib' '--with-dba' '--with-dio' '--with-dom' '--enable-ftp'
'--with-gd' '--with-ming' '--with-mysql'
'--with-mysql-sock=/var/run/mysqld/mysqld.sock' '--with-ncurses'
'--with-pcre-regex' '--enable-pcntl' '--enable-posix'
'--enable-sockets' '--enable-yp' '--with-gnu-ld'
'--with-tsrm-pthreads'
Server API => CGI
Virtual Directory Support => disabled
Configuration File (php.ini) Path => /etc/php4/php.ini
PHP API => 20020918
PHP Extension => 20020429
Zend Extension => 20021010
Debug Build => no
Thread Safety => disabled
Registered PHP Streams => php, http, ftp, compress.zlib
This program makes use of the Zend Scripting Language Engine:
Zend Engine v1.3.0, Copyright (c) 1998-2002 Zend Technologies
Configuration
PHP Core
Directive => Local Value => Master Value
allow_call_time_pass_reference => Off => Off
always_populate_raw_post_data => On => On
define_syslog_variables => On => On
disable_functions => no value => no value
display_errors => On => On
display_startup_errors => On => On
doc_root => no value => no value
enable_dl => On => On
expose_php => On => On
extension_dir => /etc/php4/ => /etc/php4/
file_uploads => On => On
gpc_order => GPC => GPC
ignore_user_abort => Off => Off
implicit_flush => On => On
include_path => .: => .:
magic_quotes_gpc => Off => Off
magic_quotes_runtime => Off => Off
max_execution_time => 30 => 30
max_input_time => -1 => -1
output_buffering => no value => no value
output_handler => no value => no value
register_argc_argv => On => On
register_globals => On => On
report_memleaks => On => On
safe_mode => Off => Off
short_open_tag => On => On
track_errors => On => On
unserialize_callback_func => no value => no value
variables_order => GPCS => GPCS
y2k_compliance => Off => Off
ctype functions => enabled
FTP support => enabled
ncurses support => enabled
User-Space Object Overloading Support => enabled
pcntl support => enabled
posix Revision => $Revision: 1.51 $
Sockets Support => enabled
YP Support => enabled
ZLib Support => enabled Compiled Version => 1.1.4
------------------------------------------------------------------------
[2003-01-24 11:26:53] [EMAIL PROTECTED]
restored mangled summary.
------------------------------------------------------------------------
[2003-01-24 10:38:06] [EMAIL PROTECTED]
Please see cgi.rfc2616_headers setting in your php.ini and see if
turning than on will solve your problem?
------------------------------------------------------------------------
[2003-01-24 09:18:37] [EMAIL PROTECTED]
This is probably because you are using the CLI version
and not the CGI version.
Could you please post a /usr/local/bin/php430 -v ?
------------------------------------------------------------------------
[2003-01-24 08:04:52] [EMAIL PROTECTED]
With PHP-CGI 4.3.0 a header("HTTP/1.x NNN Response"); is not passed
from within the script. I discovered that using Nanoweb (the PHP
webserver) running below an Apache 1.3.xx (using a wrapper script to
accomplish that).
I've used the CGI SAPI in a more usual .cgi fashion: the script was
called "nph-nww.cgi" (containing a "#!/usr/local/bin/php430"
interpreter line at the top, and it was correctly chmoded 755). Such
"nph-xxxx.cgi" scripts are treated specially by Apache. Apache does not
reparse the header()s of such .cgi's as it usually does. And now the
script actually did send a header("HTTP/1.1 200 OK\n"); but this was
not passed by this PHP-CGI-4.3.0 and Apache (because enforced not to
parse this .cgi's headers for performance reasons) did not add it of
course -> so the whole HTTP response now violates the HTTP (because the
response then begun with an arbitrary header - "Date:" in my case).
This bug occourse for PHP-CGI-5.0.0-dev as well, while previous
versions (I tested 4.2.3) passed the "HTTP/1.1" header correctly (same
script - no changes!!).
The script does something like this:
(Note it must be called "nph-whatever.cgi" to test the bug it with
Apache):
#!/usr/local/bin/php5
<?php
header("HTTP/1.1 200 OK\n");
header("X-Server: nph-whatever.cgi");
echo "<HTML>....</HTML>";
?>
Even if Apache gracefully adds the HTTP/1.1 header, this is a bug - and
I really would dislike to be enforced to use the CLI SAPI version for
CGI scripting from now on :(
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/?id=21862&edit=1
