On a related note... The Wicket Strings class provides the method stripJSessionId... http://wicket.apache.org/apidocs/1.4/org/apache/wicket/util/string/Strings.html#stripJSessionId(java.lang.CharSequence)
And the Wicket SEO wiki provides a way to remove the JSessionId... https://cwiki.apache.org/WICKET/seo-search-engine-optimization.html @Override protected WebResponse newWebResponse(final HttpServletResponse servletResponse) { return new BufferedWebResponse(servletResponse) { @Override public CharSequence encodeURL(final CharSequence url) { final String agent = ((WebRequest)RequestCycle.get ().getRequest()).getHttpServletRequest().getHeader("User-Agent"); return isAgent(agent) ? url : super.encodeURL(url); } }; } Would it be nicer to do something like this... @Override protected WebResponse newWebResponse(final HttpServletResponse servletResponse) { return new BufferedWebResponse(servletResponse) { @Override public CharSequence encodeURL(final CharSequence url) { final String agent = ((WebRequest) RequestCycle.get ().getRequest()).getHttpServletRequest().getHeader("User-Agent"); CharSequence encodedUrl = super.encodeURL(url); return isAgent(agent) ? Strings.stripJSessionId(encodedUrl) : encodedUrl; } }; } I understand why you would want to remove the jsessionid for bots, would it be "safe" to remove the jsessionid for all users to pretty up the urls? What are the implications of this and which method described above would be preferred? Martin Makundi <martin.maku...@koodaripalvelut.com> 08/04/2010 02:21 PM Please respond to users@wicket.apache.org To users@wicket.apache.org cc Subject Re: Wicket adds jsessionid to redirect onto external page Cool ;) 2010/8/4 Don Ferguson <don.fergu...@gmail.com>: > Right, it's really a jetty bug, and looks like it was fixed recently: > > http://dev.eclipse.org/mhonarc/lists/jetty-commit/msg01598.html > > > On Aug 4, 2010, at 10:46 AM, Igor Vaynberg wrote: > >> afair the servlet spec says all urls have to be passed through that >> method and thats what we do. if its not working the problem is with >> the servlet container. >> >> -igor >> >> On Wed, Aug 4, 2010 at 10:39 AM, Martin Makundi >> <martin.maku...@koodaripalvelut.com> wrote: >>> Like a sledgehammer ;) >>> >>> But yes, so it's a bug in wicket "framework design". >>> >>> ** >>> Martin >>> >>> 2010/8/4 Don Ferguson <don.fergu...@gmail.com>: >>>> Ah, much better than my approach. >>>> >>>> On Aug 4, 2010, at 8:25 AM, Martin Makundi wrote: >>>> >>>>> Hi! >>>>> >>>>> I worked around like this: >>>>> >>>>> ((org.mortbay.jetty.Request) ((WebRequest) >>>>> RequestCycle.get().getRequest()).getHttpServletRequest()).setSessionManager(null); >>>>> >>>>> >>>>> ** >>>>> Martin >>>>> >>>>> 2010/8/4 Don Ferguson <don.fergu...@gmail.com>: >>>>>> Hi Martin, >>>>>> Yes, I've encountered this. I think it's a bug in WebResponse. The culprit >>>>>> is the line: >>>>>> url = httpServletResponse.encodeRedirectURL(url); >>>>>> The url should only be encoded when redirecting to the originating site, but >>>>>> the code doesn't check. >>>>>> One workaround (short of fixing the bug) is to duplicate the functionality >>>>>> of WebResponse, commenting out the offending line. Then use it as such: >>>>>> getRequestCycle().setResponse(new NonEncodingWebResponse((WebResponse) >>>>>> getRequestCycle().getResponse())); >>>>>> getRequestCycle().setRequestTarget(new >>>>>> RedirectRequestTarget(url)); >>>>>> The source code is attached. >>>>>> >>>>>> >>>>>> -Don >>>>>> On Aug 4, 2010, at 2:22 AM, Martin Makundi wrote: >>>>>> >>>>>> Hi! >>>>>> >>>>>> I am doing something wrong? I am using: >>>>>> >>>>>> getResponse().redirect(getParameterFromRequest(RETURN_PAGE)); >>>>>> >>>>>> But the URL contains jsessionid. I think this is wrong because the >>>>>> target server does not understand the jsessiond and it returns 404 >>>>>> page not found. >>>>>> >>>>>> ** >>>>>> Martin >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>>>>> For additional commands, e-mail: users-h...@wicket.apache.org >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>>>> For additional commands, e-mail: users-h...@wicket.apache.org >>>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>>> For additional commands, e-mail: users-h...@wicket.apache.org >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>> For additional commands, e-mail: users-h...@wicket.apache.org >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org Notice: This communication, including any attachments, is intended solely for the use of the individual or entity to which it is addressed. This communication may contain information that is protected from disclosure under State and/or Federal law. Please notify the sender immediately if you have received this communication in error and delete this email from your system. If you are not the intended recipient, you are requested not to disclose, copy, distribute or take any action in reliance on the contents of this information.
