Closed
Bug 83625
Opened 24 years ago
Closed 23 years ago
Cookie dosen't get set...
Categories
(Core :: Networking: Cookies, defect)
Tracking
()
VERIFIED
FIXED
People
(Reporter: a.schild, Assigned: morse)
References
()
Details
Attachments
(1 file)
(deleted),
patch
|
Details | Diff | Splinter Review |
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9+) Gecko/20010531
BuildID: 2001053104
Cookies doesn't get accepted by Mozilla, even when allowed in the preferences.
Reproducible: Always
Steps to Reproduce:
1. Go to http://www.xtrade.ch
2. Click on one of the language links
Actual Results: The browser is redirected to a nocookies.html page, (telling us
that the cookies aren't enabled.)
Expected Results: A 4-part frameset, displaying the site content
Worked in all 0.8.x releases, I thing with 0.9 too. But not after this.
Works fine with IE and Netscape 4.x.
Perhaps related to Bug 81451
Comment 1•24 years ago
|
||
confirm with trunk build 2001-05-31-04/win2k. I can't find where the cookie
detection logic is however. Anyone have the time to find and attach the page
where the cookies are set?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Reporter | ||
Comment 2•24 years ago
|
||
The following URL's set cookies:
http://www.xtrade.ch/jindex1e.ash English
http://www.xtrade.ch/jindex1d.ash German
http://www.xtrade.ch/jindex1f.ash French
Comment 3•24 years ago
|
||
Here's what I see as the beginning of the response for the english page:
HTTP/1.0 200 OK
Content-type: text/html
Set-Cookie: AARSHOPID=0EF15GYB1002; path=/
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Frameset//EN"
"http://www.w3.org/TR/REC-html40/frameset.dtd">
<HTML>
And so on.
I'm having the same problem on 2001053108, while using a tomcat servlet sessions.
This server also uses a "Set-Cookie2" header.
Comment 5•23 years ago
|
||
Please anyone confirm if this new bug i posted (83982) is a dup of this one.
Comment 6•23 years ago
|
||
I too have this bug with tomcat, on Linux build 2001060600.
Build 2001060720 on Win98
Tomcat 3.2.2 on localhost:8080
And cookies does _not_ work, the same server works as expected on IE.
Ive tries on other sites, and there it works. So it seems to be a Tomcat-Mozilla
issue.
This bug also appears on WebLogic servlets. It seems, Mozilla just doesn't see
that the server sends a cookie, while it certainly does.
Comment 10•23 years ago
|
||
By the way, this bug occurs on a Linux version of Mozilla 0.9.1.
User agent:
Mozilla/5.0 (X11; U; Linux 2.2.17-21mdk i686; en-US; rv:0.9.1) Gecko/20010607
I had to switch to the Mozilla 0.8 in order to continue working with Weblogic
servlets.
Comment 11•23 years ago
|
||
Yes, I think I saw this bug on WinNT SP 6 running Tomcat. My Servlets work with
Mozilla 0.9 and IE 5.5 but do not work with 0.9.1.
Comment 12•23 years ago
|
||
*** Bug 84649 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 13•23 years ago
|
||
I just got around to investigating and it looks pretty serious. Appears that we
are no longer able to set session cookies that the site sends us in the http
response headers. Session cookies that the site sets via javascript should be
unaffected by this bug.
Although this wasn't reported until June 1, it actually broke (regressed) on May
11 with Darin's HTTP branch landing. What's happened is that call to
GetResponseHeader is now returning an error code if the header is not there. So
when the cookie module asks for a non-existent expiration header (as would be
the case for a session cookie), it gets back an error and therefore it doesn't
set the cookie.
Fix is simply to modify the test following the call to GetResponseHeader as
follows:
rv = aHttpChannel->GetResponseHeader("Date", getter_Copies(dateHeader));
- if (NS_FAILED(rv)) return rv;
+ if (NS_FAILED(rv) && rv != NS_ERROR_NOT_AVAILABLE) return rv;
Attaching full patch.
Assignee | ||
Comment 14•23 years ago
|
||
Assignee | ||
Comment 15•23 years ago
|
||
Vishy, please review. Alecf please superreview. This one is very serious.
Comment 16•23 years ago
|
||
Right, an HTTP/1.0 server need not send a Date header, and GetResponseHeader
was changed to return NS_ERROR_NOT_AVAILABLE (instead of NS_OK) if the requested
header is not found.
r/sr=darin
Comment 17•23 years ago
|
||
ah! I had seen this on a few sites and wondered what was up. This fix makes
sense and seems safe.
r=alecf
Comment 18•23 years ago
|
||
a=blizzard on behalf of drivers for the trunk.
Assignee | ||
Comment 19•23 years ago
|
||
*** Bug 85210 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 20•23 years ago
|
||
Fix checked in.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 21•23 years ago
|
||
*** Bug 83640 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 22•23 years ago
|
||
*** Bug 84897 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 23•23 years ago
|
||
*** Bug 81981 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 24•23 years ago
|
||
*** Bug 80714 has been marked as a duplicate of this bug. ***
Comment 25•23 years ago
|
||
*** Bug 84606 has been marked as a duplicate of this bug. ***
Comment 27•23 years ago
|
||
SORRY for this SPAM
Status:CLOSED is wron reopening
Status: CLOSED → REOPENED
Resolution: FIXED → ---
Comment 28•23 years ago
|
||
fixed...
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Comment 29•23 years ago
|
||
This bug fix DID fix the login problem on O'Reilly WebBoards, so even though
someone is re-opening this (as per last email mesaage), the problem I reported
is resovled with build number 2001061204. At least it's working now, and the
general release build of .91 is NOT.
Assignee | ||
Comment 30•23 years ago
|
||
*** Bug 85630 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 31•23 years ago
|
||
*** Bug 82185 has been marked as a duplicate of this bug. ***
Comment 32•23 years ago
|
||
*** Bug 85620 has been marked as a duplicate of this bug. ***
Comment 33•23 years ago
|
||
*** Bug 85689 has been marked as a duplicate of this bug. ***
Comment 34•23 years ago
|
||
*** Bug 84794 has been marked as a duplicate of this bug. ***
Comment 35•23 years ago
|
||
*** Bug 82463 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 36•23 years ago
|
||
*** Bug 85850 has been marked as a duplicate of this bug. ***
Comment 37•23 years ago
|
||
Verifying fixed on build 2001-06-13-09-trunk windows 98
Status: RESOLVED → VERIFIED
Comment 38•23 years ago
|
||
Request to re-open/re-evaluate:
This bug is not fully fixed as of build 2001061504. It may work where a
regular HTML page is concerned. However, when a JAVA applet (from within an
APPLET tag, which uses the Java Plug-in) makes an http request the cookie DOES
NOT get set in the request header sent to the server. This works in NS6.01 and
seems to have broken around the same time.
I have been tracing this one down for the last 3 days here and have confirmed
the following:
1. Mozilla makes an initial request to the server for a regular HTML page
2. Server generates a cookie and puts it in the response header
3. Mozilla stores the cookie
4. Mozilla makes a request for an applet page to the server setting the cookie
in the request header (which it previously stored)
4. Server accepts cookie and serves the Applet page with the same cookie in the
response header
5. Applet gets instantiated
6. Applet makes an HTTP request for some data (via URLConnection)
7. Mozilla sends the request for the data but DOES NOT put the cookie in the
request header
8. Server rejects request since there is no cookie associated with the request
and redirects to error page
9. Error page is received by the applet and throws this error into the Java
Console:
"Failed to parse the response with XML stream:
java.io.StreamCorruptedException: InputStream does not contain a serialized
object"
Requests directly from Mozilla are handled without a problem, data requests
from the Java Applet are not sending the cookie to the server.
Comment 39•23 years ago
|
||
Issues with Mozilla not telling the java plugin about cookies should be filed as
a separate bug (probably on the OJI component).
Comment 40•23 years ago
|
||
I don't think this is a Java component related issue. The data request
is/should be handled by the browser on behalf of the plug-in (regardless of the
type of plugin).
NOTE: I also, tested this with JRE 1.3.0_01/02 and JRE 1.3.1 all with the same
results.
The problem is that Mozilla (the browser) is not putting the cookie value into
the request header prior to making the request. So I still believe it is a
browser related issue.
Assignee | ||
Comment 41•23 years ago
|
||
Sounds more like a networking issue to me. From the description, it sounds like
the following is happening: when the network access is made on behalf of an
applet, the network is not calling the cookie-module listener to generate the
request headers.
Comment 42•23 years ago
|
||
I also think it is a browser related issue as passing the browser cookie to the
applet works correctly in Mozilla 0.8.1. It stopped working after Mozilla 0.9.
Assignee | ||
Comment 43•23 years ago
|
||
*** Bug 86823 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 44•23 years ago
|
||
*** Bug 86962 has been marked as a duplicate of this bug. ***
Comment 45•23 years ago
|
||
The cookie still does not get set for newsforge.com I am using 20010617 on Win95
Assignee | ||
Comment 46•23 years ago
|
||
If you are seeing a problem with newsforge, then please upon a new bug report
and give the details. Don't reopen this one which has been fixed; unless you
can demonstrate the problem with the original url of this report, you are seeing
something different.
Assignee | ||
Comment 47•23 years ago
|
||
*** Bug 87024 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 48•23 years ago
|
||
Let me clarify this since we are getting a lot of dups for it. Above I made a
comment that this has to do with session cookies. I believe I was wrong. It
instead has to do with cookies that are set when there is no "date" header in
the http response. According to darin, that would be an error on the part of
the server if it happened in HTTP/1.1. Here's is his comment from an e-mail
message:
It is the lack of the Date header which is causing the problem.
HTTP/1.1 servers are required to send a Date header, whereas HTTP/1.0
servers are not.
Comment 49•23 years ago
|
||
In my work with 2001060703 on WinME, even persistent cookies were not set... the
dialogue in here seems to suggest that this problem only affected session
cookies... if my read on this is correct, please check out <A
HREF="http://bugzilla.mozilla.org/show_bug.cgi?id=87024">87024</A> for request
and response headers that fail to set persistent cookies...
If my read is incorrect, please slap me, call me an idiot, and tell me to shut up...
-jag
Assignee | ||
Comment 50•23 years ago
|
||
OK, you're an idiot!!! You didn't read the posting that I made four minutes
before your posting. ;-)
Comment 51•23 years ago
|
||
My problem with newsforge was indeed reported as a separate bug
http://bugzilla.mozilla.org/show_bug.cgi?id=83640 But it got marked as a
duplicate of this. Please advice!
Assignee | ||
Comment 52•23 years ago
|
||
If the newsforge problem still exists even after this bug was fixed, then the
dup indicator in the other bug was incorrect. Simply reopen that bug and put a
comment indicating that it still exists.
Assignee | ||
Comment 53•23 years ago
|
||
*** Bug 87343 has been marked as a duplicate of this bug. ***
Comment 54•23 years ago
|
||
Tested on Mozilla Build ID: 2001062504
Operating System: Windows NT
This bug is incorrectly marked as a duplicate of Bug 83625 and is still not
fixed. Therefore I am requesting that it be re-opened in order to get back on
the radar.
NOTE: I am experiencing the same behavior in the most recent Mozilla build I
just downloaded and installed today.
Thanks...
Comment 55•23 years ago
|
||
Comment 56•23 years ago
|
||
As I noted in Bug 87024 I disagree with Brian. I'm using the same nightly build
that he is using and the cookie problem seems to have been resolved. I
experience none of the difficulties that were in place with M0.9.1 so I don't
believe there's any need to reopen this bug.
Again as noted in Bug 87024 I encourage Brian to dump his request/response
dialogue to try to track down the error.
-jag
Assignee | ||
Comment 57•23 years ago
|
||
*** Bug 87706 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 58•23 years ago
|
||
*** Bug 88364 has been marked as a duplicate of this bug. ***
You need to log in
before you can comment on or make changes to this bug.
Description
•