Ryan <crumley <at> gmail.com> writes: > > The reason I asked the https question before is that some servlet > containers will not allow you to access a session object that was > created during a secure http request from a non secure http request (I > know tomcat 4 has this feature, jetty 5 does not, and the servlet spec > seems to agree with tomcat). So if createVisit was called from a https > url, then later accessed via http tomcat would return null, just fyi. > > Mark; I would suggest download a firefox plugin called 'Live http > headers' (or use another solution that allows you to view all http > traffic to and from the server. Capture the traffic for the case where > the visit becomes null and where the visit does not become null then > compare the headers that were sent. My thought is that your container > sets the session cookie from one domain and somehow you end up > accessing the site from a slightly different domain causing the > session cookie not to be sent by the browser. > > ryan
After some more experimentation I have found that the route of the problem is cookies. I downloaded that Live HTTP Headers plugin for firefox by your recommendation. Everything seemed to look fine. But I noticed that no matter what user I logged in as the JSESSIONID cookie value was always the same. I am not sure if this is supposed to happen or not. But what I found is that when I disable cookies in my browser everything works fine. This seems to be because when cookies are disabled then Tapestry simply passes the JSESSIONID through a queryString parameter. So now I ask the Tapestry community. If I am having session problems and disabling cookies seems to fix the issue. What kind of problem could I have? Is this a common problem? Anyone know any solutions? --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
