Tomcat returning context path with extra leading slash (was: Re: Tomcat not properly fully-qualifying redirect URLs)

[Christopher Schultz]

All,

On 10/14/15 11:03 PM, Christopher Schultz wrote:
> All,
> 
> On 7/3/15 1:40 PM, Christopher Schultz wrote:
>> Running Tomcat 8.0.x trunk as of 1688887 (slightly old) on
>> jdk1.8.0_45 on Mac OS X, I'm having intermittent problems with
>> Tomcat appearing not to change a relative URL into a
>> fully-qualified URL for redirection purposes.
> 
>> Since it's intermittent, it's hard to catch. But I just found a
>> case.
> 
>> I have an HttpServletResponseWrapper that logs calls to
>> sendRedirect() by dumping-out the URL that was passed-into the
>> sendRedirect method.
> 
>> [snip]
> 
>> [HttpServletResponse.sendRedirect or similar is ruining my redirect
>>  URL, so the hostname is being obliterated and I get 
>> http://context/path/to/page instead of 
>> http://localhost/context/path/to/page]
> 
> I'm having this problem, again. This time with an updated 8.0.x trunk
> (pretty much 8.0.27).
> 
> It might be a problem with securityfilter, which is trying to do this:
> 
> // redirect to login page
> response.sendRedirect(response.encodeRedirectURL(request.getContextPath(
> )
> + loginPage));
> 
> The "loginPage" variable starts with a "/" and the final URL *should*
> be something like "/context/loginPage", but by the time it gets to
> HttpServletResponse.sendRedirect, it's been changed to
> "//context/loginPage". This ruins everything, of course.
> 
> I haven't stepped-through the code in a debugger, yet, but all the
> code in both securityfilter and Tomcat looks okay at first glance.
> 
> The good news is that HttpServletResponse.sendRedirect isn't making a
> bad decision. It's either securityfilter itself, or some weird
> combination of a few components, since
> o.a.c.connector.Response.encodeRedirectURL doesn't mutate the URL in a
> way that could add leading slashes.

Okay, I caught this happening again.

I have this class wrapping the request object in a Filter that does
other things -- I just re-purposed it in order to catch this problem:

    static class RequestWrapper
        extends HttpServletRequestWrapper
    {
        RequestWrapper(HttpServletRequest request)
        {
            super(request);
        }

        public String getContextPath()
        {
            String contextPath = super.getContextPath();

org.apache.log4j.Logger.getLogger("redirect").info("contextPath=" +
contextPath);
            return contextPath;
        }
    }

I got an error with the redirect, and this is what I have in my log file:

2015-10-22 13:47:33,367 [catalina-exec-6] INFO  redirect-
contextPath=//mycontext

(Note the // prefix.)

My application is deployed into an exploded WAR directory with a
META-INF/context.xml file that (correctly) declares neither a docBase
nor a path.

Later, when the redirect actually happens, the sendRedirect method
observes this:

2015-10-22 13:47:33,367 [catalina-exec-6] INFO  redirect-
encodeRedirectURL before encoding url=//mycontext/somepath&parameters


2015-10-22 13:47:33,367 [catalina-exec-6] INFO  redirect-
encodeRedirectURL after encoding url=//mycontext/somepath&parameters

2015-10-22 13:47:33,367 [catalina-exec-6] INFO  redirect- sendRedirect:
location=//mycontext/somepath&parameters

Any idea what might be causing Tomcat to return "/" + context path when
ServletContext.getContextPath() is called?

-chris

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org