On 15/02/2013 00:08, Shing Wai Chan wrote:
> I am looking at http://java.net/jira/browse/SERVLET_SPEC-43
> ("Clarify behaviour of HttpServletResponse#encodeURL() with relative URLs")
>
> In HttpServletResponse, we also have #encodeRedirectURL.
> From javadoc of #encodeRedirectURL, we have
> "All URLs sent to the HttpServletResponse.sendRedirect method should be
> run through this method."
>
> In this case, #encodeRedirectURL should be relative to current
> HttpServletRequest.
> (We need to clarify this in the spec.)
>
> Should we also apply the same "relative" principle to #encodeURL?
> If yes, then we have the following:
> * Suppose a http request comes to http://localhost:8080/a/myservlet
> * Inside myservlet, it is an error to call
> out.println(request.encodeURL("../../../../../a.jsp"));
> the url is "not" used for redirect here.
> Is it ok?
I assume you mean response.encodeURL()
I think encodeURL() and encodeRedirectURL() should be consistent.
The issue with:
request.encodeURL("../../../../../a.jsp")
is that the container has to determine if the session ID should be
encoded or not. Part of that is determining if the URL is part of the
current web application or not. For absolute URLs that is easy. For
relative URLs the question is what are they relative to? I think the
only viable answer to that question is the current request. On that
basis the example above would be
http://localhost:8080/a/myservlet/../../../../../a.jsp which is clearly
not valid.
The options at this point are:
a) ignore the problem and encode the URL anyway
b) ignore the problem and return the URL unencoded
c) throw an exception
c) might break some applications
a) just seems wrong and may have unexpected side effects
b) might break some applications but in less obvious ways than c)
I think, therefore, my preference is for c)
Mark