[ 
https://issues.apache.org/jira/browse/WICKET-5202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James Gifford updated WICKET-5202:
----------------------------------

    Attachment: jira5202.tgz

I've tweaked the Start class in the attached Quickstart app to configure Jetty 
to use url encoding. Running the Start class, hitting http://localhost:8080 and 
clicking the links three times exhibits the problem. 

Note that running Jetty via "mvn jetty:run" doesn't use the Start class and 
hence doesn't exhibit the problem. 
                
> Page redirects can fail when using url encoding
> -----------------------------------------------
>
>                 Key: WICKET-5202
>                 URL: https://issues.apache.org/jira/browse/WICKET-5202
>             Project: Wicket
>          Issue Type: Bug
>          Components: wicket
>    Affects Versions: 6.8.0
>         Environment: Linux, Tomcat 7.0.39, JDK 1.7.0
>            Reporter: James Gifford
>         Attachments: jira5202.tgz
>
>
> When url encoding is used instead of cookies for session management, some 
> redirections do not work in Wicket 6.8.0. The problem appears to be in 
> UrlRenderer.renderRelativeUrl, which returns the (invalid) relative URL:
> "..//demo/app;jsessionid=0BFE4703434CFF7BEBAE5CBF6C60B15F" 
> when passed the URL:
> "http://localhost:8080/demo/app;jsessionid=0BFE4703434CFF7BEBAE5CBF6C60B15F";
> and when the UrlRenderer's base URL is: 
> "wicket/page?1-1.ILinkListener-link"
> This is because the removeCommonPrefixes method tries to compare segments 
> between the encoded target URL and a URL parsed from 
> (URLRenderer line 319):
> Url commonPrefix = Url.parse(request.getContextPath() + 
> request.getFilterPath());
> This second URL does not contain the ;jsessionid=... suffix and the 
> removeCommonPrefixes method doesn't remove prefixes properly. The problem 
> doesn't occur when using cookies for session management, of course.
> This issue is new between Wicket version 6.2.0 and 6.8.0. When deployed into 
> a servlet container using url-encoding for session management, the following 
> app works under Wicket 6.2.0 but fails (because of redirecting to an invalid 
> URL) under Wicket 6.8.0:
> // ------------------------
> // App.java
> import org.apache.wicket.protocol.http.WebApplication;
> import org.apache.wicket.Page;
> public class App extends WebApplication {
>     @Override
>     public Class<? extends Page> getHomePage() {
>         return A.class;
>     }
> }
> // ------------------------
> // A.java
> import org.apache.wicket.markup.html.WebPage;
> import org.apache.wicket.markup.html.link.Link;
> public class A extends WebPage {
>     public A() {
>         add(new Link<Object>("link") {
>             @Override
>             public void onClick() {
>                 setResponsePage(B.class);
>             }
>         });
>     }
> }
>     
> // ------------------------
> // B.java
> import org.apache.wicket.markup.html.WebPage;
> import org.apache.wicket.markup.html.link.Link;
> public class B extends WebPage {
>     public B() {
>         add(new Link<Object>("link") {
>             @Override
>             public void onClick() {
>                 setResponsePage(A.class);
>             }
>         });
>     }
> }
> // ------------------------
> Clicking the link on the home page A will successfully navigate to page B. 
> Clicking the link on page B should navigate to page A. Under Wicket 6.2.0, or 
> Wicket 6.8.0 with cookies, it works. With Wicket 6.8.0 and url-encoding, it 
> tries to redirect to an incorrect URL like 
> http://localhost:8080/demo/app//demo/app;jsessionid=0BFE4703434CFF7BEBAE5CBF6C60B15F
> which fails (note the double slash and repeated context/filter in the URL). 
> It is possible to configure Tomcat to use url encoding instead of cookies for 
> session management by editing the conf/context.xml file within the Tomcat 
> installation and making the root element of that file read:
>  <Context cookies="false">

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to