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

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

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...

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

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.