158332 - mozilla sending cookies for invalid paths

Status: VERIFIED WORKSFORME

(Core :: Networking: Cookies, defect)

Description

[Ian Wehrman]

in recent nightlies (at least 20020718xx), mozilla has started sending cookies
with a path outside of the current request. for instance, the tomcat servlet
container sets a separate JSESSIONID cookie for each application context. when
requesting a resource under localhost:8080/ctx1, a cookie with path /ctx1 is
set. when requesting a resource under localhost:8080/ctx2 another JSESSIONID
cookie is set with path /ctx2. however, in recent nightlies, when visiting
either /ctx1 or /ctx2 (after both cookies are initially set), mozilla sends both
JSESSIONID cookies with all requests. this is quite broken, as requests inside
of /ctx1 should receive only the /ctx1 cookie, and requests inside of /ctx2
should only receive the /ctx2 cookie. among other dire consequences, this breaks
all multiple-context server session handling.

Comment 1

[Stephen P. Morse]

Can you give a sequence of steps to demonstrate the problem?

Also, is this still occuring with today's builds?  There were some changes in 
cookie path handling that went in yesterday which might have fixed this problem.

Comment 2

[Ian Wehrman]

as of the 2002071911 this still occurs. i've setup a test case similar to what i
described above. first, go to http://labfire.com:8080/ctx1/ - it will show your
jsessionid. refresh the page, and it should show the same jsessionid, and also
the jsessionid as a cookie (the page just prints your sessionid, then any
cookies sent with the request). now go to http://labfire.com:8080/ctx2/ and
follow the same procedure. this time it will show a different sessionid, but
you'll note that two different jsessionid cookies are being sent (the first of
which is from /ctx1). i've watched the cookies being sent over the wire, and
they are indeed being set with the correct path, as can also be verified in the
mozilla cookie manager. expected results are obviously to only receive the
jsessionid cookie for that particular context, which is the case in the 1.1alpha
builds. hope that helps.

Comment 3

[Stephen P. Morse]

Fix for bug 155114 has been backed out temporarily and that should fix this 
problem.  A revised fix is now in that bug report and is awaiting review.

So closing this one out as wfm.

I wanted to test out the latest patch using wehrman's test case, but 
unfortunately that URL has a problem.  I get the following error message:

   HTTP Status 500 - 
   type Exception report
   message 
   description The server encountered an internal error () that
               prevented it from fulfilling this request.

Comment 4

[Ian Wehrman]

sorry about the server being down, it's just my personal development box, and
you must have caught it while i had it taken apart. either way, i can verify
both 1.1beta and nighly 2002072221 are working now. if it crops back up, i'll
note it here and make sure the test servers are functional.

Comment 5

[Stephen P. Morse]

The server is still down.  I want to be able to verify that the latest patch in 
bug 155114 does not reintroduce this problem, but I can't do so if that server 
doesn't remain on line.

Comment 6

[Ere Maijala (slow)]

While at it, please test it against http://solo.nordea.fi also (bug 155768) :)

Comment 7

[Stephen P. Morse]

I would if I could, but that site is also down right now.  I time out waiting 
for a response.

Comment 8

[Ere Maijala (slow)]

At least now it works fine. That service is extremely reliable, I've yet to see
it fail. Maybe a dns problem somewhere? You can also try
https://solo3.nordea.fi/cgi-bin/SOLO0001.

Comment 9

[Stephen P. Morse]

OK, I was able to access the nordia.fin site.  That site violates the RFC2109 
spec.  See my comment in bug 157746 comment 20 about that, and let's continue 
that discussion therer. 

Comment 10

[Tom Everingham]

per reporters comments since backout of patch to 155114 this is working

verified wfm

need to re-test this once new patch is checked in