ID:               21862
 Updated by:       [EMAIL PROTECTED]
 Reported By:      mario17 at web dot de
-Status:           Open
+Status:           Feedback
-Bug Type:         HTTP related
+Bug Type:         CGI related
 Operating System: Debian/libc-2.3.1,-2.2.5
 PHP Version:      4.3.0
 New Comment:

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




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

[2003-01-25 09:11:50] mario17 at web dot de

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*

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

[2003-01-24 12:30:40] mario17 at web dot de

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 ?

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

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/21862

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

Reply via email to