php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #31519 Setting Status: 559 works using php-cgi but not using Apache 2 module
Submitted: 2005-01-12 17:09 UTC Modified: 2005-01-17 22:41 UTC
From: trevor dot wekel at autodesk dot com Assigned:
Status: Closed Package: Apache2 related
PHP Version: 5.0.3 OS: Windows XP
Private report: No CVE-ID: None
View Developer Edit
 [2005-01-12 17:09 UTC] trevor dot wekel at autodesk dot com 
Description:
------------
The following PHP script returns different HTTP response status codes when run using php-cgi.exe and run as a Apache module.


Versions of software installed:

PHP 5.0.3 zip donwloaded from Php.net
http://www.php.net/get/php-5.0.3-Win32.zip/from/a/mirror

Apache 2.0.52 from Apache.org
http://apache.secsup.org/dist/httpd/binaries/win32/apache_2.0.52-win32-x86-no_ssl.msi

I can also post my httpd.conf and php.ini files if required.  No special tweaking was done other than the standard PHP setup for Apache 2 documented here:

http://www.php.net/manual/en/install.windows.apache2.php



Reproduce code:
---------------
<?php
header("HTTP/1.1 559 CustomError");
header("Status: 559 CustomError");
echo "<html>\n";
echo "<body>\n";
echo "Error on page!!!\n";
echo "</body>\n";
echo "</html>\n";
?>

Expected result:
----------------
I would expect to see an HTTP response status code of 559 returned when running under both the php-cgi and the Apache 2 module.


Actual result:
--------------
When running under php-cgi, the 559 HTTP response status code is returned.  When under the Apache 2 module, an HTTP 500 Internal Error is returned.

Note:  The "Status:" line is returned correctly but it does not match the response status code.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-01-12 22:00 UTC] jed@php.net 
From the HTTP/1.1 spec, ?6.1.1:

"For example, if an unrecognized status code of 431 is received by the client, it can safely assume that there was something wrong with its request and treat the response as if it had received a 400 status code."

5xx is treated as 500 by applications that don't understand it. Why this behavior pops up in SAPI but not CGI, I'm not sure. Perhaps Apache 2 does not parse CGI return codes, but does for built-in modules?
 [2005-01-12 22:02 UTC] jed@php.net 
Sorry, cat hit "Submit" while I wasn't looking.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html#sec6.1.1

...is where that is.
 [2005-01-17 15:06 UTC] jorton@php.net 
Please try using this CVS snapshot:

  http://snaps.php.net/php5-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5.0-win32-latest.zip
 [2005-01-17 17:27 UTC] trevor dot wekel at autodesk dot com 
The unusual behaviour is still present in the 5.0.4 development snapshot when run as an Apache module.  It returns an HTTP 500 status.

Is there anything I can do on my end to determine where the response code is being dropped/remapped?

Just out of curiousity, I also tried PHP 5.0.4 dev under IIS 5.1.  Both the isapi agent and the cgi return the correct response code.  However, the isapi agent does not return the descriptive text correctly.
 [2005-01-17 20:38 UTC] trevor dot wekel at autodesk dot com 
I just finished building from the PHP 5.0.4 sources detailed below using VS .Net 2003.  I built against Apache 2.0.52 headers and applied the necessary resolve.lib patch mentioned on Zend.com.

When built locally, php5apache2.dll works correctly!  I configured with the following command line:

cscript /nologo configure.js --enable-apache2handler --without-libxml

Weird.  Are there build differences between the posted win32 executables and my local executables?
 [2005-01-17 22:41 UTC] jorton@php.net 
This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.

Thanks; the descrepancy may just have been timing on picking up the snapshots, the fix was only committed this morning.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Mon Mar 31 23:01:30 2025 UTC