Closed
Bug 99092
Opened 23 years ago
Closed 23 years ago
Cookies not being submitted in the GET request following a 401 Http code
Categories
(Core :: Networking: HTTP, defect)
Tracking
()
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.
Comment 1•23 years ago
|
||
over to http
Status: UNCONFIRMED → NEW
Component: Networking → Networking: HTTP
Ever confirmed: true
QA Contact: benc → tever
Reporter | ||
Comment 2•23 years ago
|
||
Reporter | ||
Comment 3•23 years ago
|
||
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.
Reporter | ||
Comment 4•23 years ago
|
||
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: 23 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•