A bookmarkabke url with a jsession id will not give you an page expired. So if you have only bookmarkable urls in the browser bar but the page is because of statefull components statefull. Then if a browser does refresh you get another new page of that bookmarkable page the jsessionid doesnt really do anything expect if you access the wicket session. But for a page request its not needed. Except if you use the HybridUrlEncoding.
If you are saying that the internal statefull links are a problem because the can have a page expired. Then yes thats just how it works, for that you have to create Stateless components On 10/12/08, Stefan Simik <[EMAIL PROTECTED]> wrote: > > We are creating website. One part is standard presentation web, second part > is administration site, where we take all advantages of wicket's state > management. > > The important part here, is first presentation part. > Here, all the URLs must be bookmarkable. On some special pages, we use > stateful components (Gmap2). but URL of these pages are also bookmarkable. > Usage of these stateful components forces http-session creation on these > pages. > > AT THE VERY FIRST REQUEST - this makes all our bookmarkable pages > not-bookmarkable, > because of jsessionid added by servlet container. > > This is serious problem because of: > - At the very first page - all links have jsessionid, so if the > user bookmarks any of the links, he gets Session-Expired error. > > - Bots as Google bot, Yahoo remember pages with jsessionid, ... -> but > solution for this is very easy: > - a) Use special filter, > - b) or use special Response > which cuts out the existing jsessionid string. No problem so far. > > > > > After reading this article: > http://www.nabble.com/Removing-the-jsessionid-for-SEO-td16464534i20.html#a16646137 > we thought about all possible solutions and we found this way as the best > for our web site. > Remember please, that it is for standard presentation web, where > - no jsessionid should appear > - no session-expired errors are acceptable > > I think, this will be common use case for many others. > > > 1. use filter/response, that cuts off the jsessionid if bot is detected in > User-Agent header > This solves problem for all search result URLs. > > 2. use our custom SessionExpiredPage, which has its own logic: > a) if it detects bookmarkable page -> cuts off jsessionid and redirects > to the standard bookmarkable URL > b) if it detects, that it is stateful page (by introspecting URL - for > example contains ILinkListener and path > to pagemap -> then redirect to the home page. > > We think that it is quite acceptable solution for presentation web- > see example: > You have a homepage. This page has bookmarkable URL, but has some > stateful components - for example Gmap2 map, > which is ajax component. This stateful components forces http-session > creation and makes all links with jsessionid > at the very first request. When user bookmarks some URL, he saves > stateful bookmark (with jsessionid). When user > clicks on the bookmark later, he gets Session expired error -> which > causes calling of our custom Page-Expired page. > This page introspects original Request, and detects, that it is > standard bookmarkable page, so cuts off the jsessionid, > and redirect to the normal URL, without problematic jsessionid. > > > In case 2 - where the session actually expired on some stateful page > with non-bookmarkable URL -> user will be redirected to the home page. > In case 3 - where presentation web works with user accounts and user > must be logged on some secure pages - here, session really expired -> then > special UserNotLoggedException can be thrown, and > handled by redirecting to the login page. > > > > What do you think about this solution (for eliminating PageExpired > and jsessionid on presentation web sites) ? > Are there any further pros and cons of this solution ? > > -- > View this message in context: > http://www.nabble.com/Presentation-web-with-some-stateful-components---removing-jsessionid%2B-all-PageExpired-exceptions-tp19943729p19943729.html > Sent from the Wicket - User mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
