Does the cookie come with the session id inside? I'm not sure this works this way - the value of the session id will most likely be wrong for a request one month after the last time the application was used even though the cookie itself is still valid; the session will just not exist any more on the server (unless you told tomcat / whatever to preserve sessions that long ;d). But you may be right - maybe the server can check if there is _any_ cookie to know the client supports them. When cookies come with the first request, it is the same as if it were the nth request in a series - the server can't know that. That's what sessions are for ;d
wujek On Fri, Oct 19, 2012 at 11:10 AM, Martin Grigorov <mgrigo...@apache.org>wrote: > Hi, > > On Fri, Oct 19, 2012 at 11:04 AM, Wujek Srujek <wujek.sru...@gmail.com> > wrote: > > This works more or less the following way in servlet containers: when the > > first request comes to the server, it doesn't know if cookies are > supported > > or not on the client, so it sets both the cookie and appends the > jsessionid > > I think there is a small optimization here. > The first request may come with a cookie if it is not yet expired and > then it will not encode jsessionid in the Url at all. > > > thingy that you see. Then, on another request, the container checks > whether > > a cookie is there, and now it can use the following logic: > > 1. the cookie is there: the client sent this cookie, so it supports > cookies > > - there is no need to append jsessionid every time, so the encodeUrl > > methods don't do it any more > > 2. the cookie is not there, but the jsessionid part is - this must be the > > second (or later) requrest, but cookies are not supported by the client - > > encodeUrl will now encode each url you give it to add the jsessionid part > > 3. neither the cookie nor the jsessionid part is there - this is the > first > > request in this session, so maybe create one (depends whether the app > needs > > one): set the cookie, append jsessionid and send it - this basically > starts > > the whole process again, when the server got the initial request > > > > Which means: if you disable cookies, your only option is to have > jsessionid > > encoded in the url. If you disabled cookies, and don't allow jsessionid > to > > be put (there are filters in SpringSecurity or custom solutions that > strip > > this) your application basically doesn't allow session tracking, which > > makes it stateless and most of the time pretty much useless except for > > simplest kinds. > > > > As said before, this is all done by the container; Wicket (and all other > > frameworks, for that matter) just use sessions. > > > > wujek > > > > > > On Fri, Oct 19, 2012 at 10:54 AM, Martin Grigorov <mgrigo...@apache.org > >wrote: > > > >> Hi, > >> > >> This is done by the web container (Tomcat, Jetty, ...), not by Wicket > >> itself. > >> See > >> > http://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpServletResponse.html#encodeURL(java.lang.String) > >> > >> On Fri, Oct 19, 2012 at 10:51 AM, Jordi Deu-Pons <jo...@jordeu.net> > wrote: > >> > Hi, > >> > > >> > when cookies are disable Wicket 6 attach the jsessionid in the URL > like > >> this: > >> > > >> > [app_path];jsessionid=1pwfo2de689mq100bkdc8i4jhy?[app_parameters] > >> > > >> > I'm having problems with an application that runs behind an apache > >> proxy pass. > >> > > >> > So I wonder if somebody knows, > >> > > >> > why is not using a normal URL parameter after the question mark? > >> > > >> > and > >> > > >> > is it possible to change this behaviour and force wicket to use a > >> > normal URL parameter? > >> > > >> > Thanks. > >> > > >> > -- > >> > a10! i fins aviat. > >> > J:-Deu > >> > > >> > --------------------------------------------------------------------- > >> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > >> > For additional commands, e-mail: users-h...@wicket.apache.org > >> > > >> > >> > >> > >> -- > >> Martin Grigorov > >> jWeekend > >> Training, Consulting, Development > >> http://jWeekend.com > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > >> For additional commands, e-mail: users-h...@wicket.apache.org > >> > >> > > > > -- > Martin Grigorov > jWeekend > Training, Consulting, Development > http://jWeekend.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
