You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Oscar Che (JIRA)" <ji...@apache.org> on 2012/05/24 08:58:41 UTC

[jira] [Commented] (WICKET-3258) Allow for non-relative redirects for buggy servlet containers

    [ https://issues.apache.org/jira/browse/WICKET-3258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13282240#comment-13282240 ] 

Oscar Che commented on WICKET-3258:
-----------------------------------

Hi Jeremy,
I met this problem by using wicket 1.5.4 with websphere 8.0.2. Do you have any solution to resolve this issue?  I have searched the problem but still cannot a way to get it sovled. Thanks for your time, and I do appreciate of it if you can give me a hint.

Many Thanks,
Oscar
                
> Allow for non-relative redirects for buggy servlet containers
> -------------------------------------------------------------
>
>                 Key: WICKET-3258
>                 URL: https://issues.apache.org/jira/browse/WICKET-3258
>             Project: Wicket
>          Issue Type: Improvement
>          Components: wicket
>    Affects Versions: 1.4.14, 1.5-M3
>         Environment: Websphere
>            Reporter: Jeremy Thomerson
>            Assignee: Jeremy Thomerson
>            Priority: Minor
>             Fix For: 1.4.18, 1.5.0
>
>         Attachments: relativeurlproblem.tar.gz
>
>
> There appears to be a bug in the way WebSphere handles relative URLs.  The servlet spec (http://jcp.org/aboutJava/communityprocess/final/jsr154/index.html), page 260 specifies the behavior for relative URLs, which Wicket uses, but WebSphere appears to ignore.  If we send a relative URL like "../../Something.html" to HttpServletResponse#sendRedirect, the relative path should be relative *to the requested URI* (the page I was requesting that resulted in the redirect).  WebSphere isn't implementing this behavior correctly.  Instead, it appears to interpret it as relative *to the app context and servlet mapping*.
>  
> More details:
>  
> We request a page like:
> http://[server]:[serverport]/[appcontext]/[servletmapping]/somefolder/someotherfolder/foo.html
>  
> That page results in an error, and Wicket tries to redirect to an unmounted bookmarkable page by doing sendRedirect("../../?wicket:bookmarkablePage=:com.FooPage").  This is correct according to the servlet spec, because the url passed to sendRedirect should be relative *to the requested URI* (<--- this is the key).  So, we expect the container to redirect to http://[server]:[serverport]/[appcontext]/[servletmapping]/?wicket:bookmarkable=com.FooPage .  Jetty does (and Tomcat and others).  But, WebSphere does not. 
>  
> Although I cannot look at the Websphere code, I suspect that it is interpreting this relative URL as being relative to the root of the servlet mapping.  It is then removing two folders, which takes us back to the server root (instead of the servlet mapping, like it should), removing the app context and servlet mapping (i.e. http://[server]:[serverport]/?wicket:bookmarkable=com.FooPage) This is obviously incorrect.
>  
> We have tried this compatibility setting (true and false), but it didn't work: https://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/xrun_jvm_sendredirect.html
>  
> There are a lot of reports about the problem:
> http://www.mail-archive.com/tomcat-user@jakarta.apache.org/msg68864.html
> https://issues.apache.org/jira/browse/STR-1843?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel
> http://www.mail-archive.com/struts-dev@jakarta.apache.org/msg06308.html
> Although we obviously can't fix the issue, we should provide a way for users of these servlet containers to redirect to an absolute URL rather than a relative URL.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira