Send valid HTTP status headers with PHP-CGI

Looks good.

Seems like you should use drupal_set_header within the new drupal_http_status().

I would like to see this API change get into Drupal 6.x before consideration in 5.x.

- Please do the diff with diff -up, so we see where the changes take effect.
- Please observe coding standards about concatenation, eg. look inside drupal_http_status(), things shuld be like .' '. without the spaces)
- Also look at phpdoc formatting conventions and use that: one line function summary at the start, @param broken to multiple lines
- Your second drupal_http_status() call seems to be badly indented

Apart from these, the code generally looks good, and reminds me of the approach we took on php.net, when I was active in the webmaster team.

Still to be considered for D6.
Patch was broken by centralizing _db_error_page() to database.inc.
Rerolled the patch against HEAD. Didn't test it on CGI/Fast-CGI though.

Slightly modified patch:

• Renamed drupal_http_header() to drupal_set_http_header(), to be more descriptive.
• Improved PHPdoc.
• Minor code style.

This hasn't been bumped in a while, and after my attempt to get this fixed in #81752: Incorrect headers when using PHP as CGI, this would probably best be fixed by modifing the $_SERVER['SERVER_PROTOCOL'] variable to "Status:" within drupal_initialize_variables.

Here's a patch that doesn't require a new function and only makes the change in the drupal_initialize_varibables function.

Thanks earnie, I overlooked that.

Failed due to #74645: modify file_scan_directory to include a regex for the nomask.. Setting back to code needs review.

Isn't this fixed by adjusting cgi.rfc2616_headers? As you can see in the PHP source code, PHP already translates the status code into a Status: header (the linked source is that of PHP 5.2.0 - it has been updated several times since then).

If adjusting cgi.rfc2616_headers does not fix the problem, what is the PHP bug number? There are a number of bugs that sound like this that have already been fixed in recent PHP versions.

We need a comment here to the PHP bug number so we can remove the workaround later on when it's fixed (if it hasn't been already).

I just spent far too many hours tracking this problem down with D6.1 in a CGI/FastCGI environment. In this case users were getting 500's instead of 404's. I do not believe this is a PHP bug. While setting cgi.rfc2616_headers to 0 in php.ini resolves the problem, this workaround is impractical for many who do not have access to php.ini, or who can't override php.ini settings in an .htaccess file. Additionally, it seems to me that making the headers non-compliant is (a) counter-intuitive and (b) may break other applications.

Until a permanent fix is available, I hacked the /includes/common.inc file as suggested in many other posts, but this only addresses 404 problems:

function drupal_not_found() {
  if ((substr(php_sapi_name(),0,3)=='cgi')&&(ini_get('cgi.rfc2616_headers')=='1')) {
  drupal_set_header('Status: 404 Not Found');
    }
  else {
    drupal_set_header('HTTP/1.1 404 Not Found');
  }

Similar problem.
The same website with the same code, but different responses:

GET /b1 HTTP/1.1
Host: host_with_php-cgi5

HTTP/1.1 404 Not Found
Date: Sat, 16 May 2009 03:43:06 GMT
Server: Apache/1.3.33
X-Powered-By: PHP/5.2.10-dev
Set-Cookie: SESSd62a0dd407ed7b169d8e935e80db7b4c=c2dbcf35da8c545d04866f51d241ecb9; expires=Mon, 08-Jun-2009 07:16:33 GMT; path=/; domain=. example.com
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Last-Modified: Sat, 16 May 2009 03:43:13 GMT
Cache-Control: store, no-cache, must-revalidate
Cache-Control: post-check=0, pre-check=0
Cache-Control: max-age=1209600
Expires: Sat, 30 May 2009 03:43:06 GMT
Location: http://example.com/new_location
Transfer-Encoding: chunked
Content-Type: text/html; charset=utf-8

Tested with PHP 5.2.8, 5.2.9 and latest CVS snapshot

GET /b1 HTTP/1.1
Host: host_with_mod_php4

HTTP/1.1 301 Moved Permanently
Date: Sat, 16 May 2009 03:44:33 GMT
Server: Apache/1.3.33
Cache-Control: store, no-cache, must-revalidate
Expires: Sun, 19 Nov 1978 05:00:00 GMT
X-Powered-By: PHP/4.3.10
Set-Cookie: SESSdfdd77ce611e8b8fa2de6ee9fb8957a7=98af664c1448c514cf1f2c50e4c41c0e; expires=Mon, 08-Jun-2009 07:17:59 GMT; path=/; domain=.example.com
Last-Modified: Sat, 16 May 2009 03:44:39 GMT
Cache-Control: post-check=0, pre-check=0
Location: http://example.com/new_location
Transfer-Encoding: chunked
Content-Type: text/html; charset=utf-8

There is something wrong with headers when using php-cgi
I even can't log in.

Tested on Drupal 6.11
Fix in #24 fixed only Page Not Found, but there are some problem with redirection as well.

Voting for patch #24 to be in the core.

It's related to following PHP bugs, none of them have proper solution:
http://bugs.php.net/bug.php?id=20943
http://bugs.php.net/bug.php?id=3884
http://bugs.php.net/bug.php?id=11375
http://bugs.php.net/bug.php?id=20416
http://bugs.php.net/bug.php?id=41661

Proper link to: RFC3875
http://www.ietf.org/rfc/rfc3875

See section:
6.3.3. Status

http://bugs.php.net/bug.php?id=40472

This is a configuration issue. When using PHP in CGI/FastCGI mode with CGI/1.1 compliant servers (Apache, Lighttpd, etc.) you *have* to set cgi.rfc2616-headers = 0 (which is the default).

The PHP manual has a wise word of caution:

Leave it set to 0 unless you know what you're doing.