Closed Bug 99092 Opened 24 years ago Closed 24 years ago

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

Categories

(Core :: Networking: HTTP, defect)

x86
Windows 2000
defect
Not set
major

Tracking

()

VERIFIED DUPLICATE of bug 95044

People

(Reporter: imalberto, Assigned: neeti)

Details

Attachments

(1 file)

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.
over to http
Status: UNCONFIRMED → NEW
Component: Networking → Networking: HTTP
Ever confirmed: true
QA Contact: benc → tever
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.
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 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
Verified dupe.
Status: RESOLVED → VERIFIED
QA Contact: tever → junruh
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: