|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #23902 header("HTTP/1.0 401 Authorization Required"); failed
Submitted: 2003-05-30 12:16 UTC Modified: 2003-06-03 05:15 UTC
From: noxter at web dot de Assigned: edink (profile)
Status: Closed Package: CGI/CLI related
PHP Version: 4.3.2 OS: Windows 2000
Private report: No CVE-ID: None
 [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
    Content-type: text/html
    X-Powered-By: PHP/4.3.2
    WWW-Authenticate: Basic realm="example"

the respone of CGI:

    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"


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2003-06-01 21:01 UTC]
What if you sent it as HTTP/1.1:

header("HTTP/1.1 401 Authorization Required");

Does it make any difference?

 [2003-06-02 11:43 UTC] noxter at web dot de
No difference. HTTP/1.0 or 1.1, the result is alike.
 [2003-06-02 12:42 UTC]
This works:

    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.

 [2003-06-02 14:12 UTC]
Yeah, I started on a fix for it yesterday and will look at it again tonight.  Not sure who wrote the header stuff, but not checking for NULL is the problem here.
 [2003-06-03 01:56 UTC]
Since my testing appears to show that rfc2616_headers *DOES NOT* work with IIS/5.0, I'm reasigning this to the author of that code.  However, the patch below 'fixes' the (null) problem, and properly allows full status lines to be used with the authenticate header.  This bug is related to bug 19207.

With rfc2616_headers=1 on IIS/5.0, the following occurs (IIS/5.0 likes rfc2616_headers=0, oposite of comments in php.ini):

C:\usr\src\php43>wget -S http://localhost/auth.php43d
--23:54:42--  http://localhost/auth.php43d
           => `auth.php43d.4'
Resolving localhost... done.
Connecting to localhost[]:80... connected.
HTTP request sent, awaiting response...
 1 HTTP/1.1 200 OK
 2 Server: Microsoft-IIS/5.0
 3 Date: Tue, 03 Jun 2003 06:54:42 GMT
 4 HTTP/1.0 401 Authorization Required
 5 Content-type: text/html
 6 X-Powered-By: PHP/4.3.3-dev
 7 WWW-Authenticate: Basic realm="example"

    [ <=>                                 ] 4              3.91K/s

Index: main/SAPI.c
RCS file: /repository/php4/main/SAPI.c,v
retrieving revision
diff -u -d -u -r1.155.2.9 SAPI.c
--- main/SAPI.c	11 Feb 2003 23:30:13 -0000
+++ main/SAPI.c	3 Jun 2003 06:48:47 -0000
@@ -456,6 +456,12 @@
 static void sapi_update_response_code(int ncode TSRMLS_DC)
+	/* if the status code did not change, we do not want
+	   to change the status line, and no need to change the code */
+	if (SG(sapi_headers).http_response_code == ncode) {
+		return;
+	}
 	if (SG(sapi_headers).http_status_line) {
 		SG(sapi_headers).http_status_line = NULL;
Index: sapi/cgi/cgi_main.c
RCS file: /repository/php4/sapi/cgi/cgi_main.c,v
retrieving revision
diff -u -d -u -r1.190.2.37 cgi_main.c
--- sapi/cgi/cgi_main.c	31 May 2003 17:02:01 -0000
+++ sapi/cgi/cgi_main.c	3 Jun 2003 06:48:47 -0000
@@ -303,7 +303,7 @@
 	if (SG(sapi_headers).http_response_code != 200) {
 		int len;
-		if (rfc2616_headers) {
+		if (rfc2616_headers && SG(sapi_headers).http_status_line) {
 			len = snprintf(buf, SAPI_CGI_MAX_HEADER_LENGTH, 
 						   "%s\r\n", SG(sapi_headers).http_status_line);

 [2003-06-03 03:11 UTC]
cgi.rfc2616_headers directive was added in response to bug #19207. Later changes to SAPI.c made it malfunction.
 [2003-06-03 05:15 UTC]
I have applied Shane's patch which solves the problem with (Null) in the header output.

cgi.rfc2616_headers should be left to 0 if basic authentication is used under IIS and PHP cgi as Shane noted.

In order to make it work you would need to edit in your IIS configuration 'Directory Security'. Click on 'Edit' and check only 'Anonymous access'. All other fields should be left empty. will contain the fix in some 3 hours or so.
 [2003-06-04 18:17 UTC] ptchristendom at yahoo dot com
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:'); ?>

d:\php-4.3.2\php script.php
Content-type: text/html; charset=iso-8859-1
X-Powered-By: PHP/4.3.2

Setting cgi.rfc2616_headers = 0 is a workaround for this, at least until the bug is fixed.
 [2003-06-05 04:05 UTC] jan at kneschke dot de
Doesn't IIS parse CGI headers ? 
If it does: 
CGI-script are not allowed to send HTTP-response headers at 
all. If a CGI script wants to pass a status-code to the Server by 
stetting the Status-header. 
Section 7.2 
removing the HTTP-response header is a good thing for 
Parser-Header environments.
 [2010-04-20 08:49 UTC] dim_logaras at windowslive dot com
i forgot my username for ip addres
 [2010-04-20 08:55 UTC] taverna_ambelos at windowslive dot com
i forget my adress for ip
 [2010-08-27 22:48 UTC] mmoohh00 at yahoo dot com
i wanna make apassword for my wireless lan
 [2010-09-15 01:32 UTC] enzinho_vrb at hotmail dot com
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Jul 18 21:01:27 2024 UTC