You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Christopher Schultz <ch...@christopherschultz.net> on 2015/10/15 05:03:50 UTC
Re: Tomcat not properly fully-qualifying redirect URLs
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJWHxeWAAoJEBzwKT+lPKRYAQMQAKXjLuWehajKAc1OpoN4YJyo
+YBXN9xUGrYUJOKRIrEveaI/RrgU7OzfgA1n3A4wSIIu4NFzxwJYZnBGpCgCLo75
7qmoc+ikHUd5OxYkTsQ2SD03e9A3bZQDUeNwt6FvfUeMTBNHwsrRRmBW7PLyJNwN
FSFIroI1kURBm2SEn+uXlJ3WdQtAJC0XzIxa4lfiq6rU8Hwnx/aGAr/tkcQmXIi1
iWefdR2iYpvG5PqADbwqmLxzt3dWqJH6RCLeFRrtnqjK4gB0sDpoFNTj8if8RYkT
8L90k0ZcPzM4WJJWSJPZdnDAjHWUGEycbZkHk87AXl4xZkvQ/pmYQSAqWF+w1/hx
sVvgrbTonv0gK8jFNdm/RVp5C6dI44/EZloHmKkeuVj+geMbejo0xKA4hi1CUalU
nLb/NysBq9cfFU4foc/dpYn21Mixro+SLNStbQgwVq/jncHsLu80uKoP9QAkMjvY
OGuGQilYL+q3Hk6No5dRhDEdK2fAQ0Oi0SFb7LK4qS+6RQdBw9TDsOlOMFRPYAFW
slbstyHnevx9u2YgJw9P6BCc4dcxPcgJkjAal8uuPNBRuBWknoV7BQ4Tc/kFvpRP
eGnb0pVf9fXVb89majicQzNSf4aec8zTYxyToPj4jW6hlpjjxnZLhbHwHnNZvWaW
lDsyARINmf2kuKkX4gJj
=oRAf
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat returning context path with extra leading slash
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Konstantin,
On 10/23/15 6:32 AM, Konstantin Kolinko wrote:
> 2015-10-22 20:55 GMT+03:00 Christopher Schultz <ch...@christopherschultz.net>:
>> 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));
>>>
> <...>
>>
>> Any idea what might be causing Tomcat to return "/" + context path when
>> ServletContext.getContextPath() is called?
>
> It seems that you are confusing two different methods,
>
> (1) HttpServletRequest.getContextPath()
> (2) ServletContext.getContextPath(), @since Servlet 2.5
>
> (1) returns the actual value from client's request, as is
> (2) returns "canonical" value
>
> (2) is always the same, (1) varies
Aah, I didn't realize that they were different.
I'll look into why HttpServletRequest.getContextPath is returning the
"extra" slash -- probably because of something that has happened
previously in the workflow.
Thanks,
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat returning context path with extra leading slash (was: Re:
Tomcat not properly fully-qualifying redirect URLs)
Posted by Konstantin Kolinko <kn...@gmail.com>.
2015-10-22 20:55 GMT+03:00 Christopher Schultz <ch...@christopherschultz.net>:
> 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));
>>
<...>
>
> Any idea what might be causing Tomcat to return "/" + context path when
> ServletContext.getContextPath() is called?
It seems that you are confusing two different methods,
(1) HttpServletRequest.getContextPath()
(2) ServletContext.getContextPath(), @since Servlet 2.5
(1) returns the actual value from client's request, as is
(2) returns "canonical" value
(2) is always the same, (1) varies
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Tomcat returning context path with extra leading slash (was: Re:
Tomcat not properly fully-qualifying redirect URLs)
Posted by Christopher Schultz <ch...@christopherschultz.net>.
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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org