|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #21862 CGI SAPI header("HTTP/1.1 CODE Response") not passed
Submitted: 2003-01-24 08:04 UTC Modified: 2003-02-25 02:05 UTC
Avg. Score:3.2 ± 1.1
Reproduced:1 of 1 (100.0%)
Same Version:2 (200.0%)
Same OS:1 (100.0%)
From: mario17 at web dot de Assigned:
Status: No Feedback Package: CGI/CLI related
PHP Version: 4.3.0 OS: Debian/libc-2.3.1,-2.2.5
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2003-01-24 08:04 UTC] mario17 at web dot de
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):
   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 :(


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2003-01-24 09:18 UTC]
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 10:38 UTC]
Please see cgi.rfc2616_headers setting in your php.ini and see if turning than on will solve your problem?
 [2003-01-24 11:26 UTC]
restored mangled summary.
 [2003-01-24 12:30 UTC] mario17 at web dot de
I've (now) tried the
(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/ (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

Date: Fri, 24 Jan 2003 18:05:43 GMT
Server: aEGiS_nanoweb/ (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 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


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-25 09:11 UTC] 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
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-02-25 02:05 UTC]
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.

PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Sun Sep 25 20:05:52 2022 UTC