Closed
Bug 83625
Opened 24 years ago
Closed 24 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•24 years ago
|
||
Please anyone confirm if this new bug i posted (83982) is a dup of this one.
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•24 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•24 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.
Assignee | ||
Comment 13•24 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•24 years ago
|
||
Assignee | ||
Comment 15•24 years ago
|
||
Vishy, please review. Alecf please superreview. This one is very serious.
Comment 16•24 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•24 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
Assignee | ||
Comment 20•24 years ago
|
||
Fix checked in.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 27•24 years ago
|
||
SORRY for this SPAM Status:CLOSED is wron reopening
Status: CLOSED → REOPENED
Resolution: FIXED → ---
Comment 28•24 years ago
|
||
fixed...
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Comment 29•24 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.
Comment 37•24 years ago
|
||
Verifying fixed on build 2001-06-13-09-trunk windows 98
Status: RESOLVED → VERIFIED
Comment 38•24 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•24 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•24 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•24 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•24 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.
Comment 45•24 years ago
|
||
The cookie still does not get set for newsforge.com I am using 20010617 on Win95
Assignee | ||
Comment 46•24 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 48•24 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•24 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•24 years ago
|
||
OK, you're an idiot!!! You didn't read the posting that I made four minutes before your posting. ;-)
Comment 51•24 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•24 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.
Comment 54•24 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•24 years ago
|
||
ooops! I incorrectly put my comment intended for Bug 87024 in here. Sorry folks. This comment was supposed to be: Bug 87024 has been incorrectly marked as a duplicate of this bug. Bug 87024 is still seems broken in the latest build (id# 2001062504).
Comment 56•24 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
You need to log in
before you can comment on or make changes to this bug.
Description
•