|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[2003-05-30 12:16 UTC] noxter at web dot de
The follow example failed by php as common gateway interface application. This problem is common and not specified of a server. Testing with apache, iis, devwex ... . The option cgi.rfc2616_headers = 1 is setting in the php.ini.
<?
header("HTTP/1.0 401 Authorization Required");
header("WWW-Authenticate: Basic realm=\"example\"");
?>
the response of Server :
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Fri, 30 May 2003 17:04:01 GMT
(null)
Content-type: text/html
X-Powered-By: PHP/4.3.2
WWW-Authenticate: Basic realm="example"
the respone of CGI:
(null)
Content-type: text/html
X-Powered-By: PHP/4.3.2
WWW-Authenticate: Basic realm="example"
...
the respone correct is:
HTTP/1.0 401 Authorization Required
Content-type: text/html
X-Powered-By: PHP/4.3.2
WWW-Authenticate: Basic realm="example"
...
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Fri Oct 24 02:00:01 2025 UTC |
What if you sent it as HTTP/1.1: header("HTTP/1.1 401 Authorization Required"); Does it make any difference?This works: <?php header("WWW-Authenticate: Basic realm=\"example\""); header("HTTP/1.0 401 Authorization Required"); ?> For Shane: Seems that when line sapi/cgi/cgi_main.c:307 is reached, the SG(sapi_headers).http_status_line is reset to NULL in line main/SAPI.c:591 (matters only when cgi.rfc2616_headers = 1). Not sure if this is bug in SAPI.c (or not even a bug) but CGI SAPI should handle this a bit better, at least by not setting that "(null)\r\n" header line.On windows 2003, PHP 4.3.2, any location header at all causes this. You can also verify it from the command line: script.php contains this line only: <? header('Location: http://localhost.com/page.html'); ?> Output: d:\php-4.3.2\php script.php (null) Content-type: text/html; charset=iso-8859-1 X-Powered-By: PHP/4.3.2 Location: http://localhost.com/page.html Setting cgi.rfc2616_headers = 0 is a workaround for this, at least until the bug is fixed.