|
|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[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):
#!/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 :(
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Wed Oct 29 13:00:01 2025 UTC |
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*