On 2/15/13 5:51 AM, Mark Thomas wrote:
> 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)
In this case, we should throw a runtime exception, say
IllegalArgumentException.
>
> Mark
>