-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Tim,
On 6/24/15 7:15 AM, Tim Watts wrote: > 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? That might made sense if this was working as expected in Tomcat 7 but not Tomcat 6, but it's the other way around. I'm thinking something else is going on... it's tough to get responses from the OP, but they keep posting new threads just in case someone else wants to give it a try... - -chris -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVir+pAAoJEBzwKT+lPKRYAyEP/3GMWH86+pm1n9uSlSNdzTZ6 MkU4g5cyaIBrYiz2KAGJaaQgJZ0dOCYWjMF68MG40g4NmRK6OcJmAGYK2fl7Co0x 9INFrGk8sMhlcs5ssiijk5AF+d3B/9eZRYoX2YFTWzlSxL8Tttz/LDN6pjx3m1Am 6u9soq0zrIoOpsMLelfQtCBAUgjqtUOIlgG/8+3ufxbvJizhLq4QzQ49rzYzfizc HkoorxzeSbwFaIzl2Gqnm2NcBg/lHM85mxRL8aIcK2yHIoMoHYqu6J24U353uOzM YK0pZypZXDveOfvmWrK01NPYGMLK1IhTR/vB+TwjbZQeVtg25H/xFttXq4NsOBlR EZgEbrma4pNlHofXVLL8sC/y/SSl7H/7MmRvVmJNG96gHmqN1SnaOoNprwtB24lY IZN4flZ9Ur3tblW2PE/xVlWTn6bcirheTopne56lpQUbc8ff2s2tRajcBpCsjL+e GgDjRG6lpigfOGPZKZ3lILWEtzytQXz+VPfEdHjFoaH0pIFOXPYFoTocopnrFHwz zTZ0RK7Uda0FY56KHPEBljhmOHnn1CzcMY/VGISLC61FpGadL7hmvwppuFIoMIZQ I5Ouu3kq2/vrMmOlfLnttWl9T2jP/4PBE36H7oMrboDDA5CJrrV2qo01tD3m8ghR mN3TxA/TKKTVxqTp8lWT =u+vX -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
