On 04/03/2013 22:54, Shing Wai Chan wrote:
> 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.
Works for me.
Mark