Closed Bug 227506 Opened 21 years ago Closed 21 years ago

Mozilla does not handle multiple cookies in HTTP header correctly

Categories

(Core :: Networking: Cookies, defect)

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

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: spepping, Assigned: darin.moz)

References

(
URL
)

Details

Attachments

(2 files)

Analysis with cookie log and http header for session in apache's bugzilla
2.92 KB, text/plain
Details
Analysis with cookie log and http header for session in mozilla's bugzilla
4.34 KB, text/plain
Details 
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 Firebird/0.7
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 Firebird/0.7

When I browse Mozilla's or Apache's Bugzill I have to renew my login constantly.
I have investigated this with cookie logs, http headers. My conclusion is that
multiple cookies in a HTTP header are not treated well by Mozilla. This occurs
in MozillaFireBird 0.6, 0.7 and Mozilla 1.4, 1.5. See attachments for details
from cookie logs and http headers.

Reproducible: Always

Steps to Reproduce:
1. Log in to bugzilla.
2. Browse a bit.
3. Go to a page that requires login, e.g. enter a new bug.
4. Login is requested again.
5. Create an attachment to the bug.
6. Login is requested again, and attachment is spoilt.
Actual Results:  
Described above. From cookie log I see that the second and third cookies are not
recognized by Mozilla. Specifically, Bugzilla_login cookie is accepted,
Bugzilla_logincookie cookie is not.

Expected Results:  
Recognize each separate cookies, accept them and send them to the server on the
next requests.
The problem does not occur with MozillaFirebird 0.6 on Windows 2000.

This bug looks like 193951, but the headers and cookie logs show different 
symptoms.


I can use bugzilla just fine.
From the logs, it seems there is something with the expires date. "rejected
because cookie has already expired". But also the newline -> comma conversion
shouldn't happen afaik.
Can you try to set up a simple testcase?
The problem with the expiry date is a bug with the Bugzilla version that apache
uses; it is not Mozilla's problem. Mozilla's problem is that both in the Apache
as in the Mozilla case it does not treat the multiple cookies properly. In the
Apache case, it rejects all three cookies, while it should accept the first two
cookies, just like the Windows version of Mozilla does.

The newline -> comma conversion may be a signal of the problem.

What test case do you want me to set up? I think I have attached good test
cases. Probably this very session will turn out in another test case.

The fact that you cannot reproduce it means that not all Mozilla builds have the
problem, but the four builds that I tested definitely have the problem.
cookie log from this same session:
two cookies sent, one cookie accepted:

1024[80c1588]: ===== COOKIE ACCEPTED =====
1024[80c1588]: request URL: http://bugzilla.mozilla.org/process_bug.cgi
1024[80c1588]: cookie string: Bugzilla_login= spepping%40leverkruid.nl ; path=/;
expires=Sun, 30-Jun-2029 00:00:00 GMT,Bugzilla_logincookie=323099 ; path=/;
expires=Sun, 30-Jun-2029 00:00:00 GMT
1024[80c1588]: current time: Sat Dec 06 19:04:29 2003 GMT
1024[80c1588]: ----------------
1024[80c1588]: name: Bugzilla_login
1024[80c1588]: value: spepping%40leverkruid.nl
1024[80c1588]: host: bugzilla.mozilla.org
1024[80c1588]: path: /
1024[80c1588]: expires: Fri Jun 29 23:59:49 2029 GMT
1024[80c1588]: is secure: false
1024[80c1588]: 

next request:
Old Bugzilla_logincookie=253551 sent. Previous response set this cookie to
323099, but this was not recognized and not accepted.

1024[80c1588]: ===== COOKIE SENT =====
1024[80c1588]: request URL: http://bugzilla.mozilla.org/show_bug.cgi?id=227506
1024[80c1588]: cookie string: Bugzilla_login=spepping%40leverkruid.nl; BUGLIST=;
LASTORDER=bugs.bug_status%2C%20bugs.priority%2C%20map_assigned_to.login_name%2C%20bugs.bug_id;
Bugzilla_logincookie=253551; VERSION-Browser=other; PLATFORM=Browser
1024[80c1588]: current time: Sat Dec 06 19:05:40 2003 GMT

I am sure that when I commit this comment, I have to renew my login, even though
I have just logged in to commit my previous comment.
Comment on attachment 136830 [details]
Analysis with cookie log and http header for session in apache's bugzilla

>Set-Cookie: Bugzilla_login=me@mynew.email ; path=/; expires=Sun,
>+30-Jun-2029 00:00:00 GMT
>Set-Cookie: Bugzilla_logincookie=50463 ; path=/; expires=Sun, 30-Jun-2029
>+00:00:00 GMT
>Set-Cookie: Bugzilla_password= ; path=/; expires=Sun, 30-Jun-80 00:00:00 GMT

So, we have three cookies, one with expiry somewhere in the year 80 (1980?)

>3. On Windows Mozilla shows this cookie log. Note that it recognizes
>   three cookies and rejects only one.
>
>0[2f4780]: ===== COOKIE ACCEPTED =====
>0[2f4780]: name: Bugzilla_login

Cookie 1 is accepted

>0[2f4780]: ===== COOKIE ACCEPTED =====
>0[2f4780]: name: Bugzilla_logincookie

Cookie 2 is accepted

>0[2f4780]: ===== COOKIE NOT ACCEPTED =====
>0[2f4780]: request URL: http://nagoya.apache.org/bugzilla/query.cgi
>0[2f4780]: cookie string: Bugzilla_password= ; path=/; expires=Sun, 30-Jun-80
>+00:00:00 GMT
>BUGLIST=
>0[2f4780]: current time: Mon Dec 01 08:34:31 2003 GMT
>0[2f4780]: rejected because cookie has already expired

Cookie is rejected, because the expiry date is wrong. (i'm not sure if it is
really wrong, but it looks like it)

So i'm not seeing a problem with multiple cookies here.
Oh, i think i see the problem. You are interpreting the logs wrong.
When you set two cookies in one header, two entries will show up in the log. The
first will have both cookies in the cookie-string, while only the first is
really parsed. The second entry shows only the second cookie in the
cookie-string, and the results of parsing that cookie.
So, there should be more in the log after the snippet you just pasted.
I have been unclear in my description.

The bug report applies to my Linux versions of Mozilla. 

The first cookie log in the first attachment, from a session at apache's
bugzilla, is from Mozilla on Linux: It shows that the cookie (i.e. all three
cookies) is rejected because of the expiry date problem. This is wrong
behaviour. The correct behaviour would be to accept two cookies and to reject
the last one.

The second cookie log in the first attachment, again from a session at apache's
bugzilla, is from Mozilla on Windows 2000. It is there for comparison. It
accepts two cookies, and rejects one because of the expiry date. This is correct
behaviour.

The cookie log in the second attachment, from a session at Mozilla's bugzilla,
is again from Mozilla on Linux. It shows that two cookies are sent, but only one
is accepted, the cookie called Bugzilla_login. The other one, called
Bugzilla_logincookie, is simply not recognized. This is incorrect behaviour.

The second attachment includes the headers as reported by ethereal from the same
session at Mozilla's bugzilla, on Linux. They show clearly that and how the two
cookies are sent.

The second attachment also includes the headers as reported by livehttpheaders,
from the same session at Mozilla's bugzilla, from Mozilla on Linux. It shows the
content of the two cookies collapsed in a single header line. This is consistent
with Mozilla's behaviour, probably because it uses the same code. It is
incorrect behaviour when we compare it with ethereal's data.

I hope this will clarify my intent better.

I use libc-2.2.5.so and libm-2.2.5.so on a Debian Woody system.
So it seems like something is cenvertring the multiple set-cookie headers into
one, seperated by comma's. Do you use some proxy? Are you using debians version
of mozilla? if so, please try a build from ftp.mozilla.org
Yes, I am using a proxy: the wwwoffle program. And that is the culprint. When I
turn it off, it goes allright, see this cookie log from the login to this
session. The second cookie is accepted, and the correct Bugzilla_logincookie
cookie is return, preserving the validity of my login:

1024[80c1588]: ===== COOKIE ACCEPTED =====
1024[80c1588]: request URL: http://bugzilla.mozilla.org/query.cgi
1024[80c1588]: cookie string: Bugzilla_login= spepping%40leverkruid.nl ; path=/;
expires=Sun, 30-Jun-2029 00:00:00 GMT
Bugzilla_logincookie=323135 ; path=/; expires=Sun, 30-Jun-2029 00:00:00 GMT
1024[80c1588]: current time: Sat Dec 06 21:16:40 2003 GMT
1024[80c1588]: ----------------
1024[80c1588]: name: Bugzilla_login
1024[80c1588]: value: spepping%40leverkruid.nl
1024[80c1588]: host: bugzilla.mozilla.org
1024[80c1588]: path: /
1024[80c1588]: expires: Fri Jun 29 23:59:50 2029 GMT
1024[80c1588]: is secure: false
1024[80c1588]: 
1024[80c1588]: ===== COOKIE ACCEPTED =====
1024[80c1588]: request URL: http://bugzilla.mozilla.org/query.cgi
1024[80c1588]: cookie string: Bugzilla_logincookie=323135 ; path=/; expires=Sun,
30-Jun-2029 00:00:00 GMT
1024[80c1588]: current time: Sat Dec 06 21:16:40 2003 GMT
1024[80c1588]: ----------------
1024[80c1588]: name: Bugzilla_logincookie
1024[80c1588]: value: 323135
1024[80c1588]: host: bugzilla.mozilla.org
1024[80c1588]: path: /
1024[80c1588]: expires: Fri Jun 29 23:59:50 2029 GMT
1024[80c1588]: is secure: false
1024[80c1588]: 
1024[80c1588]: ===== COOKIE SENT =====
1024[80c1588]: request URL: http://bugzilla.mozilla.org/show_bug.cgi?id=227506
1024[80c1588]: cookie string: Bugzilla_login=spepping%40leverkruid.nl;
Bugzilla_logincookie=323135; PLATFORM=Browser; VERSION-Browser=other; BUGLIST=;
LASTORDER=bugs.bug_status%2C%20bugs.priority%2C%20map_assigned_to.login_name%2C%20bugs.bug_id
1024[80c1588]: current time: Sat Dec 06 21:18:53 2003 GMT

Because it is a local proxy, ethereal comes before it and does not register its
mangled header. Therefore it seems to be an error of the proxy, and I have
bothered you for no reason. Sorry.



I have now instructed Mozilla not to use the proxy for bugzilla.mozilla.org.
Indeed, committing the previous comment went without problems. I did not have to
renew my login. So, yes, it is definitely the proxy.


ok, closing this bug :)
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: