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

Darryl L. Miles commented on WICKET-4625:
-----------------------------------------

WICKET-4625 ServletWebRequest#getContextRelativeUrl() removes extra leading 
character 

Defensive patch that work in all scenarios addresses sanitization of the
filterPrefix argument to ensure it has both a leading and trailing slash.

The goal of the patch is to remove the extra "+1" being added to 'start'
computation and causes the return value to remove the first character of
the relative URI.  

It was found that the filterPrefix argument may or may not have a leading
slash, also the filterPrefix argument may or may not have a trailing slash.
It would also return complete nonsense when the given 'uri' did not match  
the contextPath and/or filterPrefix.

The method needs to work when
  contextPath="/context" and 
  contextPath=""
  never contextPath="/context/" (not valid input data)
  never contextPath="/" (an empty string is correct, a single slash is not 
valid)

The method needs to work when
  filterPrefix="" (when there is no prefix)
  filterPrefix="/prefix/" (which is the form seen from debuging real 
applications)
  filterPrefix="prefix/" (which is the form seen suring unit testing, this is
     also the format of data currently stored in WicketFilter#filterPath)
  never filterPrefix="/" (an empty string is correct, a single slash is not 
valid)
  never filterPrefix="prefix" (not valid input data)

So often the +1 would be correct (more by luck than engineering), and then
sometimes it would be incorrect.

The need for ensuring filterPath has a leading slash is that when
Unit testing the method MockHttpServletRequest#getFilterPath() removes
the leading slash and causes that prefix to end up at the filterPrefix
argument to the #getContextRelativeUrl() method.

Under my limited real world application testing I have never seen the
leading slash removed from the filterPrefix when debugging the method
#getContextRelativeUrl() and I suspect this is a test case only scenario
being catered for here due the way the Mock object is written.

This patch passes all wicket.git project unit tests for me.

                
> ServletWebRequest#getContextRelativeUrl() sometimes chops off leading 
> characters
> --------------------------------------------------------------------------------
>
>                 Key: WICKET-4625
>                 URL: https://issues.apache.org/jira/browse/WICKET-4625
>             Project: Wicket
>          Issue Type: Bug
>            Reporter: Darryl L. Miles
>
> This patch reduces the number of nonsense return value this method might 
> produce.  I have clarified the in JavaDoc the expected inputs to the method.  
> It is still possible to still get a nonsense return values in some use cases, 
> all scenarios are documented and tested in a new test case.
> This method presumes that the input "uri" on the 1st argument always has the 
> ContextPath and then the FilterPrefix on the front of the URL.
> Some unit tests were actually checking the nonsense return values were being 
> returned these have been updated.

--
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

        

Reply via email to