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: