Topic
  • 1 reply
  • Latest Post - ‏2013-10-24T13:22:49Z by bergmark
wujasmarecki
wujasmarecki
1 Post

Pinned topic WLP 8.5.5 and Apache Wicket

‏2013-10-23T09:03:36Z |

Hello, 

I have found the same issue valid for the WLP V8.5.5 - http://stackoverflow.com/questions/16787785/wicket-was-calling-url-causes-a-redirect-to-a-wrong-url-causing-404

If this is a WLP bug it would be nice to get it fixed. 

 

Marek Zajac

  • bergmark
    bergmark
    42 Posts

    Re: WLP 8.5.5 and Apache Wicket

    ‏2013-10-24T13:22:49Z  

    At this point I'm not convinced this is a WLP bug.  Here is what I think happens:

     

    1) Request comes in for some URL that there is no application mapped servlet for.  For example "/a/b/c.html".  As no servlet mappings match this path, it gets handled by the servlet containers file handling processor which is mapped "/*"

    2) As the file handling processor is mapped to /*, the servletPath will be an empty string, and the rest of the URI will be in the pathInfo.  This appears to match the behavior defined in Section 3.5 of the Servlet 3.0 specification.

    3) A filter in the chain calls response.sendRedirect with a relative path prior to the request being handled by the processor mentioned above.  Section 5.3 that talks about sendRedirect doesn't provide a lot of detail of how this relative path gets translated to a full qualified one.  The best match I could find in the specification was 9.1 where it discusses using the RequestDispatcher for relative paths, which says:

    "The servlet container uses information in the request object to transform the given relative path against the current servlet to a complete path."   

    I believe the WLP Servlet Container is effectively doing this, but the servletPath is empty so it appears like it is relative to the contextRoot.

    There is a custom property mentioned in the Wicket JIRA issue that when enabled should append the pathInfo onto the relative path when redirecting.  It is "com.ibm.ws.webcontainer.redirectwithpathinfo"