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¶meters
2015-10-22 13:47:33,367 [catalina-exec-6] INFO redirect-
encodeRedirectURL after encoding url=//mycontext/somepath¶meters
2015-10-22 13:47:33,367 [catalina-exec-6] INFO redirect- sendRedirect:
location=//mycontext/somepath¶meters
Any idea what might be causing Tomcat to return "/" + context path when
ServletContext.getContextPath() is called?
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
