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)
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•24 years ago
|
||
over to http
Status: UNCONFIRMED → NEW
Component: Networking → Networking: HTTP
Ever confirmed: true
QA Contact: benc → tever
Reporter | ||
Comment 2•24 years ago
|
||
Reporter | ||
Comment 3•24 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•24 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: 24 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•