You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Paul Frieden <pf...@dchain.com> on 2000/09/27 20:19:14 UTC

[PATCH] Re: Session cookies, jvmRoute, and the root context

I haven't heard anything back about this, so I thought I would send it
again and flag it as a patch.  yhs, do you have a test case that can
reliably produce the problem?  If so, would be be much trouble to try
this patch?  I wasn't able to properly delete cookies before, but I can
now with this patch.

Paul

Paul Frieden wrote:
> 
> I've started looking into the cookie behavior, and I think I may have
> found one problem, but I'm not sure if the fix fixes everything yet.  In
> the example below, it never states that it is using version 1 cookies,
> so I will assume that it is using the default version 0 cookies.  I
> threw together a few JSP pages that work with cookies.  I not only
> couldn't change the values properly, I couldn't reliably delete the
> cookies at all.
> 
> I went into the RFC that defines cookies and did some research there.
> The RFC is available at http://www.w3.org/Protocols/rfc2109/rfc2109.
> That current code sets the Expires header to be the current time on the
> server plus the MaxAge.  In the case of a MaxAge of 0, that makes the
> Expires time be the current time on the server.  The RFC refers to
> setting a date long in the past to forcefully expire a cookie.  I made
> some changes to the code in org.apache.tomcat.utils.CookieTools, and
> that seems to at least let me reliably delete cookies.  The code
> currently uses MaxAge >= 0.  That treats MaxAge of 0 exactly the same as
> a non-0 MaxAge and bases it off of the current time.  I've added a
> condition to detect MaxAge == 0 and version == 0 that sets the time way
> into the past.
> 
> On an interesting note, Netscape on Linux doesn't like a cookie
> expiration time of "Thu, 01-Jan-1970 00:00:00 GMT".  It will not delete
> the cookies properly.  If I move the time a few hours later though, it
> works great.
> 
> Why doesn't the current time force the browser to delete the cookie?
> I'm guessing that the way the time is used it disregards the locale and
> the difference between the server's time and the browsers time.  Why
> does it not show this behavior with no load balancing?  I have no idea
> yet.  The patch might not be perfect, but I didn't want to mess up the
> version 1 cookie handling because that seems to work.
> 
> Paul Frieden
> 
> "yhs@mimic.onesourcecorp.com" wrote:
> >
> > Hi paul,
> >
> > I've quoted josephs msg below as well as yours. To be specific on whats
> > broken and needs to be fixed :
> > Here's the first part of it :
> > ---------------
> > http://znutar.cortexity.com/BugRatViewer/ShowReport/27
> > Report Description:
> >      I have two servers with identical servlets on both doing load
> > balancing (1 JVM per server). For this example consider A1 to be servlet A
> > running on server 1 and so on, B2 to be servlet   B on server 2 etc.
> > A1 -> set cookie to (say) abc=20
> > B2 -> reads from the cookie. gets abc=20. correct.
> > C2 -> deletes the cookie     (setMaxAge to 0)
> > C2 -> sets a new cookie abc=30
> > C2 -> reads from the cookie. gets abc=30. correct.
> > B1 -> reads from the cookie.     gets abc=20 <---------------- bug.
> > B2 -> reads form the cookie. gets abc=30. correct.
> > I'm using mod_jserv.so to do the load balancing. using
> >      netscape 4.73 to access the servlets and tomcat 3.2b2 with blackdown
> > JDK 1.2.2FCS on redhat linux 6.2 kernel 2.2.16-3. I cant offer any insight
> > into whats causing it...AFAIK this
> >      behaviour was not present in 3.1 and changing the JDK doesnt help. it
> > only occurs with load balancing and not with the regular non load balanced
> > operation. It doesnt affect me any
> >      more since i've worked around it and dont care either way....but it
> > shouldnt really be present anyway
> > ---------------
> >
> > The second part is the jvmRoute thingy (josephs patch) which works for
> > root only but breaks multiple servlet contexts. This needs to be fixed and
> > ensure that it works in BOTH non loadbalanced as well as loadbalanced
> > environments (i recommend testing with 250 concurrent users with at least
> > 50 concurrent JVMS on two machines to be sure).
> >
> > The third part is that cookies dont work for lynx. period. either lynx or
> > tomcat or the jdk needs to be patched. it should be a clean patch
> > tho...cant afford to break netscape/IE/opera/etc and fix lynx.
> >
> > Thats it....as i said earlier its unlikely that a huge patch which fixes
> > all of these things without breaking anything else will be included in 3.2
> > or even 3.3....i dont really care either way, but it would be nice to have
> > it fixed.