Closed Bug 83625 Opened 23 years ago Closed 23 years ago

Cookie dosen't get set...

Categories

(Core :: Networking: Cookies, defect)

Product:
Core
Component:
Networking: Cookies
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: a.schild, Assigned: morse)

References

(
URL
)

Details

Attachments

(1 file)

Not an error if expiration header is not found
754 bytes, 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
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
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
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.
Please anyone confirm if this new bug i posted (83982) is a dup of this one.
I too have this bug with tomcat, on Linux build 2001060600.
Tomcat servlet sessions seem to be fixed on 2001060620.
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.
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.
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.
*** Bug 84649 has been marked as a duplicate of this bug. ***
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.
Vishy, please review. Alecf please superreview. This one is very serious.
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
ah! I had seen this on a few sites and wondered what was up. This fix makes sense and seems safe. r=alecf
a=blizzard on behalf of drivers for the trunk.
Blocks: 83989
*** Bug 85210 has been marked as a duplicate of this bug. ***
Fix checked in.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
*** Bug 83640 has been marked as a duplicate of this bug. ***
*** Bug 84897 has been marked as a duplicate of this bug. ***
*** Bug 81981 has been marked as a duplicate of this bug. ***
*** Bug 80714 has been marked as a duplicate of this bug. ***
*** Bug 84606 has been marked as a duplicate of this bug. ***
It's relay working now.
Status: RESOLVED → CLOSED
SORRY for this SPAM Status:CLOSED is wron reopening
Status: CLOSED → REOPENED
Resolution: FIXED → ---
fixed...
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
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.
*** Bug 85630 has been marked as a duplicate of this bug. ***
*** Bug 82185 has been marked as a duplicate of this bug. ***
*** Bug 85620 has been marked as a duplicate of this bug. ***
*** Bug 85689 has been marked as a duplicate of this bug. ***
*** Bug 84794 has been marked as a duplicate of this bug. ***
*** Bug 82463 has been marked as a duplicate of this bug. ***
*** Bug 85850 has been marked as a duplicate of this bug. ***
Keywords: mostfreq
Verifying fixed on build 2001-06-13-09-trunk windows 98
Status: RESOLVED → VERIFIED
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.
Issues with Mozilla not telling the java plugin about cookies should be filed as a separate bug (probably on the OJI component).
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.
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.
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.
*** Bug 86823 has been marked as a duplicate of this bug. ***
*** Bug 86962 has been marked as a duplicate of this bug. ***
The cookie still does not get set for newsforge.com I am using 20010617 on Win95
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.
*** Bug 87024 has been marked as a duplicate of this bug. ***
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.
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
OK, you're an idiot!!! You didn't read the posting that I made four minutes before your posting. ;-)
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!
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.
*** Bug 87343 has been marked as a duplicate of this bug. ***
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...
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).
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
*** Bug 87706 has been marked as a duplicate of this bug. ***
*** 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.

Attachment

General

Creator:
Created:
Updated:
Size: