RE: Relative redirects in light of recent changes

[George Stanchev]

<quote>
> However, with useRelativeRedirects="false" I see
> 
> GET http://hostname/myapp?m=n&o=p 
>               ==> 302: "http://hostname/login?a=b&c=d";
> 
> The questions I have are 2: First, what happened with the trailing slash 
> redirect. I vaguely remember discussions around it but I couldn't find them 
> on the mailing list search index. And secondly but more importantly, in 
> 7.0.64, the HttpServletRequest.sendRedirect() would use the application name 
> to form the Location header value (as in .../myapp/login...) whereas in 
> 7.0.67 the name of the application is missing from the absolute redirect.
> 
> Is there any way to work around this and to have 7.0.67 behave like 7.0.64?

Setting mapperContextRootRedirectEnabled="true" on the Context should fix it.

Mark
</quote>

Thanks Mark. So if I understand correctly, 7.0.68 will return to adding the 
trailing slash automatically just like 7.0.64 did. That for now can be worked 
around by setting that attribute above on the context for now.

With the trailing slash optional though, the code in 
"org.apache.catalina.connector.Response#toAbsolute(String)" still seems will 
yield wrong redirect URLs for the case where someone is running with trailing 
slash redirect disabled:

                    String relativePath = request.getDecodedRequestURI();
                    int pos = relativePath.lastIndexOf('/');
                    ...
                    } else {
                        encodedURI = urlEncoder.encodeURL(relativePath, 0, pos);
                    }

In case of relativePath being "/myapp" (which will be the case when somone runs 
with traliling-slash-redirect being turned off), encodedURI will be "".

So it seems to me either TC should *always* force those 
trailing-slash-redirects or fix the code above to correctly calculate the 
encodedURI from the relativePath...

George