87024 - Cookies told to set in HTTP header do not set

Status: RESOLVED DUPLICATE of bug 83625

(Core :: Networking: Cookies, defect)

Description

[Joshua Ginsberg]

I've run my web services using the same user authentication scheme for some time
now. However, in this most recent stable release of Mozilla (2001060703), I am
unable to set http cookies in client browsers, persistent or session-only.

For example, on team.wiess.rice.edu a user requests a access restricted page
with the following headers (it's pulled from debug output in my server logs so
the formatting isn't right, but the content is there):

Request: GET /home/ HTTP/1.1
Other header: {Host team.wiess
.rice.edu} {User-Agent {Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.1) G
ecko/20010607}} {Accept {text/xml, application/xml, application/xhtml+xml, text/
html;q=0.9, image/png, image/jpeg, image/gif;q=0.2, text/plain;q=0.8, text/css,
*/*;q=0.1}} {Accept-Language en-us} {Accept-Encoding gzip,deflate,compress,ident
ity} {Accept-Charset {ISO-8859-1, utf-8; q=0.667, *; q=0.667}} {Keep-Alive 300}
{Connection keep-alive}

My server then responds with:
HTTP/1.0 302 OK
MIME-Version: 1.0
Set-Cookie: browserid=278; path=/; expires=Fri, 01-Jan-2010 01:00:00 GMT
Location: http://team.wiess.rice.edu/home/login.tcl?returnhref=home%2findex%2etc
l%3f

This Set-Cookie command is in accordance with Netscape's published cookie spec
(http://home.netscape.com/newsref/std/cookie_spec.html). If there's another spec
I should be using, please let me know what that is. This is the one pointed to
by most documentation I can find.

So then the second request comes in for the login script:
Request: GET /home/login.tcl?returnhref=home%2findex%2etcl%3f HTTP/1.1
Other header: {Host team.wiess.rice.edu} {User-Agent {Mozilla/5.0 (Windows; U;
Win 9x 4.90; en-US; rv:0.9.1) Gecko/20010607}} {Accept {text/xml,
application/xml, application/xhtml+xml, text/html;q=0.9, image/png, image/jpeg,
image/gif;q=0.2, text/plain;q=0.8, text/css, */*;q=0.1}} {Accept-Language en-us}
{Accept-Encoding gzip,deflate,compress,identity} {Accept-Charset {ISO-8859-1,
utf-8; q=0.667, *; q=0.667}} {Keep-Alive 300} {Connection keep-alive}

Notice that the browserid cookie is absent from the headers. The user enters the
login data and then that form information is passed to another script. Then the
script that handles login request compares the given login data to the database
and when verified, returns the following header.

HTTP/1.0 302 OK
MIME-Version: 1.0
Set-Cookie: browserid=279; path=/; expires=Fri, 01-Jan-2010 01:00:00 GMT
Set-Cookie: sessionid=txa91SV4plc4o; path=/
Set-Cookie: userid=198; path=/
Location: http://team.wiess.rice.edu/home/index.tcl?

It's setting a new browserid (for the browserid that's lacking) as a permanent
cookie, and then it's trying to set session-only cookies for sessionid and
userid. However, in redirecting to the page that originally required
user-authentication (http://team.wiess.rice.edu/home/), the client requests:

Request: GET /home/index.tcl? HTTP/1.1
Other header: {Host team.wiess.rice.edu} {User-Agent {Mozilla/5.0 (Windows; U;
Win 9x 4.90; en-US; rv:0.9.1) Gecko/20010607}} {Accept {text/xml,
application/xml, application/xhtml+xml, text/html;q=0.9, image/png, image/jpeg,
image/gif;q=0.2, text/plain;q=0.8, text/css, */*;q=0.1}} {Accept-Language en-us}
{Accept-Encoding gzip,deflate,compress,identity} {Accept-Charset {ISO-8859-1,
utf-8; q=0.667, *; q=0.667}} {Keep-Alive 300} {Connection keep-alive} {Referer
http://team.wiess.rice.edu/home/login.tcl?returnhref=home%2findex%2etcl%3f}

And then, the user authentication cookies lacking, the server redirects back to
the login page, again trying to set a persistent browserid cookie:

HTTP/1.0 302 OK
MIME-Version: 1.0
Set-Cookie: browserid=280; path=/; expires=Fri, 01-Jan-2010 01:00:00 GMT
Location: http://team.wiess.rice.edu/home/login.tcl?returnhref=home%2findex%2etcl%3f

No other browser that uses my system exhibits this behavior. MSIE, Netscape 4,
Netscape 6 (20010131), they all handle the cookies properly.

I haven't tested to see if it's because I'm returning a 302 header instead of a
200, but that's a possibility I'll check if so requested. Any other information
I can provide would be most helpful.

Thanks!

-jag

Comment 1

[Stephen P. Morse]

*** This bug has been marked as a duplicate of 83625 ***

Comment 2

[bcortez]

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 3

[Joshua Ginsberg]

As the original reporter, I have to say I disagree with Brian. I'm also using
2001062504 and the solution thathas been in place for several days now (at least
since 20010622) still works for me.

Brian, I'd encourage you to spit out your request/response dialogue to see where
the problem is.

-jag

Comment 4

[bcortez]

Thanks....  The behavior I'm seeing may be a different bug.  I'll 'get my ducks 
in a row' then file a new bug report for this behavior.