On Wed, 2015-06-24 at 11:55 +0200, André Warnier wrote: > Hi. > > Hi. > > The recommendation on this forum is to not use "top posting", but to keep the > flow of > conversation natural, and respond below the question to which your question > refers. > See http://tomcat.apache.org/lists.html, "Important", 6) > I have modified you latest post accordingly below. > > chedana jayasinghe wrote: > > On Tue, Jun 23, 2015 at 2:46 PM, André Warnier <a...@ice-sa.com> wrote: > > > >> chedana jayasinghe wrote: > >> > >>> In my web application, in a jsp there is a javascript which sends request > >>> to a servlet every twenty seconds, so it kills my applications user idle > >>> time tracking by resetting the lastAccessed time in session. the funny > >>> thing is lastAccessed time doesn't get updated in tomcat 6 and my > >>> applications idle time tracking works fine in it, but in 7 it gets updated > >>> and kills that functionality of the application . so I'm little bit > >>> confused about the changes in the session tracking of tomcat 6 and tomcat > >>> 7. > >>> > >>> > >> I don't know what happened in Tomcat 6 as compared to what happens in > >> other versions. > >> But from a purely logical point of view, I would tend to think that, from > >> the server point of view, whether a request comes from the user pressing a > >> button or from a javascript module in a page sending a request, does not > >> make a difference : the application has been accessed, so the "last > >> accessed time" should be updated. > >> That is probably the point even, of many such javascript snippets out > >> there in the wild. > >> > >> So again from a purely logical point of view, if Tomcat 6 then did not > >> update the last access time, that would sound more like a bug, that was > >> corrected later. > >> > >> Maybe the fact that it updates this or not, depends on whether the > >> application that is called retrieves the session or not, and if so you may > >> have control over it, by making sure that whatever your javascript calls, > >> it does /not/ retrieve the session. > >> > >> Caveat : I do not really /know/ how it works, so there is a lot of > >> speculation here. > >> > > > I just put a debug point an checked. In tomcat 6,the request comes to the > > servlet with a null session,but in tomcat 7 and later versions the valid > > session is there in the request > > > > Yes, but the /call/ that contains this jsession-id, comes from the javascript > that is in > the HTML page currently shown in the browser. > So the question is : why does that /call/, now, contain this jsessionid > parameter, when > under Tomcat 6 it did not ? > > Or to put this another way : how does the local javascript in the browser > *know* this > jsession-id ? > > Or in yet another way : the javascript in the browser does not /know/ if it > is talking to > a Tomcat 6 or a Tomcat 7 or a Tomcat 8 server, right ? So how comes that in > one case, it > sends a request /without/ a jsessionid, and in the other cases /with/ a > jsessionid ? > Haven't been following this thread too closely, so ignore this if it's a total non sequitur, but perhaps TC6 does NOT mark the cookie as HttpOnly while later versions do?
> > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
