Closed Bug 138489 Opened 23 years ago Closed 23 years ago

cookies getting lost when space appears in domain= attribute

Categories

(Core :: Networking: Cookies, defect, P2)

Product:
Core
Component:
Networking: Cookies
Platform:
x86
Windows 98
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.1beta

People

(Reporter: bear_phillips, Assigned: morse)

References

Details

Attachments

(1 file)

remove leading spaces in domain attribute
1.21 KB, patch
samir_bugzilla
: review+
alecf
: superreview+
chofmann
: approval+
Details | Diff | Splinter Review 
I just upgraded to 1.0 RC 1.  My site uses apache/mod_perl/auth_cookie for
authentication.  When logging in, the site sets three cookies.  I turned on
cookie notification and it pops up three times, but only the first two cookies
are set.  I don't have this problem with IE or Mozilla 9.9.

I tried setting cookies with a simple perl script using cgi.pm but couldn't
reproduce the problem.  If it helps, the piece of perl code in auth_cookie.pm
that sets the cookies looks like:
  $r->err_headers_out->add("Set-Cookie" => $cookie);
  $r->err_headers_out->add("Set-Cookie" => $cookie2);
  $r->err_headers_out->add("Set-Cookie" => $cookie3);

thanks
chad
Please read the bug writing guidelines. Can we have a testcase please ?
At least the URL of a site we can check against.
Sorry about not leaving more info.

Here is the test case
http://members.aafp.org/members/junk.html

Just leave everything blank and hit "Enter the Site"

Using mozilla 9.9 I get these cookies:
Domain           Cookie Name
aafp.org         aafpid
aafp.org         Auth::AuthCookieHandler_WhatEver
members.aafp.org Auth::AuthCookieHandler_WhatEver
members.aafp.org

Using mozilla 1.0 rc1 I get these cookies:
Domain           Cookie Name
aafp.org         Auth::AuthCookieHandler_WhatEver
members.aafp.org Auth::AuthCookieHandler_WhatEver
members.aafp.org

The cookie named aafpid is not being stored when I use 1.0 rc1.

thanks
chad
gphillip@aafp.org
On Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020419 I also only
get the latter set of cookies. I have not checked if this is correct, though.
But if so, it seems to be OS=ALL.

pi
-> cookies
Assignee: Matti → morse
Component: Browser-General → Cookies
QA Contact: imajes-qa → tever
I found why this is occuring.  When my server sets the cookie it uses mod_perl and  
$r->err_headers_out->add("Set-Cookie" => $cookie);

The $cookie contained "aafpid=7160134; path=/; domain= .aafp.org; "

Notice the extra space between domain= and .aafp.org.  I took out the space and
now Mozilla 1.0rc1 picks it up fine.  With the space, Mozilla 1.0 would drop the
cookie.  Mozilla .99 and earlier and IE were more forgiving had no problems with
the space.  

Anyway, I not sure if this should be considered a Mozilla bug.
Yes, it should be considered as a mozilla bug since it's something we can easily 
fix and something that IE handles correctly.  However, now that the cause is 
known, I would no longer consider it as major.
Severity: major → normal
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Target Milestone: --- → mozilla1.0.1
I made a test case for this.  It is at
http://members.aafp.org/cgi-bin/test.pl
I should set a cookie with this:
name=mozilla
value=test
domain= .aafp.org

With the 4-17 build, the cookie does not get set because of the extra space in
the domain name.  
thanks
chad
Target Milestone: mozilla1.0.1 → mozilla1.1alpha
Summary: cookies getting lost → cookies getting lost when space appears in domain= attribute
Priority: -- → P2
Target Milestone: mozilla1.1alpha → mozilla1.1beta
Unable to use either of the posted examples cited in this report.  So, instead, 
here is an example that demonstrates the problem:

  <html>
    <body>
      <script>
        document.cookie = "a=b;domain= .netscape.com";
      </script>
    </body>
  </html>

and upload this to some user account in my.webpage.com (of course you need 
to open a free netscape account first).  Alternately you can upload this to any 
server of your choice and change the " .netscape.com" in the example above to 
reflect the domain of your server.

To demonstrate this test, bring up the page in the browser and then use the 
cookie manager to see if the cookie gets set.  It should, but due to this bug it 
is not getting set.
Comment on attachment 90565 [details] [diff] [review]
remove leading spaces in domain attribute

sr=alecf
Attachment #90565 - Flags: superreview+
Comment on attachment 90565 [details] [diff] [review]
remove leading spaces in domain attribute

r=sgehani
Attachment #90565 - Flags: review+
Checked in on trunk.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment on attachment 90565 [details] [diff] [review]
remove leading spaces in domain attribute

a=chofmann for 1.0.1, if there are any addtional test cases or side effects
that can be tested for lets get them in this bug.  add the fixed1.0.1 keyword
after checking into the branch.
Attachment #90565 - Flags: approval+
Keywords: mozilla1.0.1+
Keywords: nsbeta1
If this can be checked in ASAP for 1.0 branch it could still make 1.0.1
Approved for branch on 7/11

It's not been checked into the branch because it never received adt approval.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: