Re: Hide page version query parameters
On Tue, Jan 3, 2012 at 1:20 AM, Igor Vaynberg igor.vaynb...@gmail.com wrote: add the nofollow attribute to such links. All the links had it from the start. The crawlers from the big companies (Google, Bing etc) obey it, but some smaller ones do not. Anyways, I fixed the problem by filtering the bad parameters with urlrewritefilter. So no more internal server errors. Regards, Taneli Korri - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Hide page version query parameters
On Mon, Jan 2, 2012 at 9:47 AM, Martin Grigorov mgrigo...@apache.org wrote: On Mon, Jan 2, 2012 at 8:18 AM, Taneli Korri tko...@gmail.com wrote: On Sat, Dec 31, 2011 at 4:31 PM, Martin Grigorov mgrigo...@apache.org wrote: On Sat, Dec 31, 2011 at 2:29 PM, Taneli Korri tko...@gmail.com wrote: On Sat, Dec 31, 2011 at 9:09 AM, Martin Grigorov mgrigo...@apache.org wrote: On Fri, Dec 30, 2011 at 11:43 PM, martin.dilger martin.dil...@googlemail.com wrote: hi, you could try to change your render strategy to redirect to render, that would dismiss the page parameters version. This is not correct. The page id is encoded in the url only for stateful pages. Make your page stateless and it wont be there. OK, thanks for the info. If I remember correctly, in Wicket 1.4 stateful pages had also clean urls if the page was mounted to a certain path, i.e. the page version number was stored somewhere behind the scenes. I'm guessing this isn't possible anymore in Wicket 1.5? Everything is possible. The new IRequestMapper are easily extensible and you can even use your own one. By default this special parameter is set so when the user presses F5 (Refresh) the page Wicket will deliver the same version of the page. Otherwise a new instance will be created without the knowledge of the exact version. Why do you want to hide this parameter ? Plain and simple, I like clean urls that can be bookmarked. The urls with the page id can be bookmarked. If the requested version of the page is not available then a new version is created and delivered. Ok, I think I can live with that. :) Also some of the search engine bots save the crawled urls (with parameters) and try to access them at a later time. I found this out when I updated one of my sites and now I'm seeing a lot of 500 Internal error responses in my web server logs. Can you paste the stacktrace of an exception caused by such request ? I should have been more clear, this case wasn't directly related to the page version parameter, but to clean urls. The thing is that I had a few stateful links in the frontpage which changed the page stylesheet. Now when I have removed the links, I'm seeing some crawlers still trying to request them. For example, a get request to /?0-1.ILinkListener-stylechooser-style1wicket:interface=:1:stylechooser:style2::ILinkListener:: throws this with Wicket 1.5.3: ERROR org.apache.wicket.DefaultExceptionMapper - Unexpected error occurred org.apache.wicket.request.handler.ComponentNotFoundException: Could not find component 'stylechooser:style1' on page 'class net.korri.www.page.blog.BlogPage at org.apache.wicket.request.handler.PageAndComponentProvider.getComponent(PageAndComponentProvider.java:167) at org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.getComponent(ListenerInterfaceRequestHandler.java:92) at org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.invokeListener(ListenerInterfaceRequestHandler.java:248) at org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.respond(ListenerInterfaceRequestHandler.java:234) at org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:750) at org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64) at org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:252) at org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:209) at org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:280) at org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:162) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:218) at com.caucho.server.dispatch.FilterFilterChain.doFilter(FilterFilterChain.java:87) at org.tuckey.web.filters.urlrewrite.RuleChain.handleRewrite(RuleChain.java:176) at org.tuckey.web.filters.urlrewrite.RuleChain.doRules(RuleChain.java:145) at org.tuckey.web.filters.urlrewrite.UrlRewriter.processRequest(UrlRewriter.java:92) at org.tuckey.web.filters.urlrewrite.UrlRewriteFilter.doFilter(UrlRewriteFilter.java:381) at com.caucho.server.dispatch.FilterFilterChain.doFilter(FilterFilterChain.java:87) at com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:187) at com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:265) at com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:273) at com.caucho.server.port.TcpConnection.run(TcpConnection.java:682) at com.caucho.util.ThreadPool$Item.runTasks(ThreadPool.java:743) at com.caucho.util.ThreadPool$Item.run(ThreadPool.java:662) at java.lang.Thread.run(Thread.java:662) The request was valid earlier, but now since I've changed the site there's
Re: Hide page version query parameters
On Sat, Dec 31, 2011 at 4:31 PM, Martin Grigorov mgrigo...@apache.org wrote: On Sat, Dec 31, 2011 at 2:29 PM, Taneli Korri tko...@gmail.com wrote: On Sat, Dec 31, 2011 at 9:09 AM, Martin Grigorov mgrigo...@apache.org wrote: On Fri, Dec 30, 2011 at 11:43 PM, martin.dilger martin.dil...@googlemail.com wrote: hi, you could try to change your render strategy to redirect to render, that would dismiss the page parameters version. This is not correct. The page id is encoded in the url only for stateful pages. Make your page stateless and it wont be there. OK, thanks for the info. If I remember correctly, in Wicket 1.4 stateful pages had also clean urls if the page was mounted to a certain path, i.e. the page version number was stored somewhere behind the scenes. I'm guessing this isn't possible anymore in Wicket 1.5? Everything is possible. The new IRequestMapper are easily extensible and you can even use your own one. By default this special parameter is set so when the user presses F5 (Refresh) the page Wicket will deliver the same version of the page. Otherwise a new instance will be created without the knowledge of the exact version. Why do you want to hide this parameter ? Plain and simple, I like clean urls that can be bookmarked. Also some of the search engine bots save the crawled urls (with parameters) and try to access them at a later time. I found this out when I updated one of my sites and now I'm seeing a lot of 500 Internal error responses in my web server logs. Regards, Taneli Korri - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Hide page version query parameters
On Sat, Dec 31, 2011 at 9:09 AM, Martin Grigorov mgrigo...@apache.org wrote: On Fri, Dec 30, 2011 at 11:43 PM, martin.dilger martin.dil...@googlemail.com wrote: hi, you could try to change your render strategy to redirect to render, that would dismiss the page parameters version. This is not correct. The page id is encoded in the url only for stateful pages. Make your page stateless and it wont be there. OK, thanks for the info. If I remember correctly, in Wicket 1.4 stateful pages had also clean urls if the page was mounted to a certain path, i.e. the page version number was stored somewhere behind the scenes. I'm guessing this isn't possible anymore in Wicket 1.5? Regards, Taneli Korri - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Hide page version query parameters
Allen wrote Is there a built-in way to hide page version parameters (e.g. ?12) in Wicket 1.5? If not, is it possible to write a custom IRequestMapper that does so without screwing up proper request handling? Hi, Did you find a way to remove the page version parameter? I'm also trying to figure out how to achieve that in Wicket 1.5. In 1.4 it was easy since, mounting the page with mountBookmarkablePage was enough. Regards Taneli Korri -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Hide-page-version-query-parameters-tp4163099p4240312.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: RequestLogger and session invalidation
On Thu, May 28, 2009 at 11:24 AM, Johan Compagner jcompag...@gmail.comwrote: why are you using invalidateNow? I was using it for invalidating sessions on logout. But since plain invalidate() works, and doesn't break RequestLogger, my original problem is fixed. Regards, Taneli Korri
Re: RequestLogger and session invalidation
On Thu, May 28, 2009 at 6:49 AM, Jeremy Thomerson jer...@wickettraining.com wrote: Please open a JIRA so this doesn't get lost. I haven't looked, but it sounds wrong if it truly recreates an invalidated session in some end-of-request logging, even if it doesn't bind the session. Post the link back here. I found out what's causing the problem, I was using Session.invalidateNow() which invalidates the session before it's logged. With Session.invalidate() the problem doesn't exist. I created a JIRA issue about it: https://issues.apache.org/jira/browse/WICKET-2291 Regards, Taneli Korri
RequestLogger and session invalidation
Hi, I'm using Wicket 1.3.6 and RequestLogger.getLiveSessions to get the current sessions in my web application, but I'm experience strange behaviour when session invalidation occurs. When the user logs out of the application, the session is invalidated. This leads to WebApplication.sessionDestroyed to be called, which removes the session from the RequestLogger.liveSessions Map and everything seems to be fine. But the execution continues and eventually RequestCycle.detach gets called, which leads to RequestLogger.requestTime. And that's where the strangest thing happens, on line 254 of RequestLogger.java the invalidated session is created again and added back to the liveSessions Map. Is this the expected behaviour? Since this ensures that the liveSessions Map includes all sessions, even the invalidated ones. And another thing, are there any downsides in keeping RequestLogger on in production environment? I'm thinking that it might hog a lot of resources, but is that the case? Regards, Taneli Korri
