99092 - Cookies not being submitted in the GET request following a 401 Http code

Status: VERIFIED DUPLICATE of bug 95044

Description

[alberto chan]

From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (Windows NT 5.0; U)
BuildID:    2001080110

Repeatable on Mozilla 0.9.3.
Works fine on Netscape 4.77
--
Let's say mozilla is trying to access a resource on a server. There should be 
some kind of plugin on the server that will look for the "Authorization: " 
header and decrypt the credentials. If no "Authorization: " header is found, the 
plugin should set a cookie (FIRST_GET=true e.g) and then send a 401 Http code 
back to the browser. The resource itself is irrelevant, so I'll use GET to 
represent a request.

On the first GET, the server sets a cookie (make sure the cookies are for the 
duration of the browser session) in the response and then send a 401 http code 
to the browser since there is no "Authorization: " header. The browser 
challenges the user for basic credentials (401). When the user click "OK", the 
browser sends back the "Authorization: Basic hex_encoded_credentials" header as 
expected but there is *no* "Cookie: " header at all attached in the second GET.

Since there are vaild credentials on the second GET, the browser is 
authenticated/authorized. On the other hand if the server is expecting the 
cookies it set in the response on the first GET, the application on the server 
will break.

Reproducible: Always
Steps to Reproduce:
Using Tomcat 323:
1. Write a request interceptor that will be called on every request. The 
interceptor should check for the "Authorization " header. If there is no header, 
set a cookie (e.g. FIRST_GET=true) when the browser tries to access a resource 
(in my test case, it is a servlet that dumps cookies in the request. See step 
2). If the header is found, allow the browser to access the resource.
2. write a servlet (the resource) that will dump all cookies coming in on the 
second GET.
3. from browser, access resource. the server will challenge. enter credentials 
and submit to server. the servlet application should dump all cookies (expected 
behavior), but you will see none (the bug).


Actual Results:  The servlet application does not see any cookies set by the 
request interceptor.

Expected Results:  Mozilla should set the "Cookie: " header on the second GET. 
The servlet will then see all cookies set by the request interceptor set in the 
response on the first GET.

Even though the bug deals with authentication/authorization, I filed it under 
the Networking module as the "Authorization: Basic" header is set as expected.

I understand that writing the tomcat request interceptor and the servlet to dump 
the cookies are not 3 minutes tasks. Anybody familiar with Perl and Apache could 
probably do the same thing in less time.

This is not the easiest bug to describe. Let me know if anybody need more 
details.

Comment 1

[Boris Zbarsky [:bzbarsky, bz on IRC]]

over to http

Comment 2

[alberto chan]

Created attachment 48937 [details]
Source code which simulate a simple Http Listener on a specified port.

Comment 3

[alberto chan]

I have attached a very simple http listener that you guys can use to replicate 
the problem. 

To Compile:
javac -d . HttpListener 

To Run:
java -classpath . HttpListener <port> 

This should set the cookie FIRST_REQUEST=YES in the browser and submit 
credentials and you won't see the cookie being sent back. 

It also occured to me that may be 401 Http Code is considered an error code and 
hence the browser should discard all cookies that may have been set. 

Comment 4

[alberto chan]

Sorry for the havoc, but I was looking through the code for nsHttpChannel.cpp 
using lxr in my attempt to may be submit a fix for the bug and I came across bug 
95044 (which is a duplicate of this bug) which has already been fixed.

Can somebody mark this bug 99092 as a duplicate of bug 95044.

Thanks.



*** This bug has been marked as a duplicate of 95044 ***

Comment 5

[John Unruh]

Verified dupe.