[SERVLET_SPEC-43] Clarify behaviour of HttpServletResponse#encodeURL() with relative URLs Created: 28/Jul/12  Updated: 06/Mar/13  Resolved: 06/Mar/13

Status: Resolved
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: markt_asf Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The Javadoc for HttpServletResponse#encodeURL() states that "The implementation of this method includes the logic to determine whether the session ID needs to be encoded in the URL."

The Javadoc gives one example of a test. Another possible test that may be performed is "Is the URL part of the web application?". If it is not, the session ID does not need to be encoded in the URL.

That highlights the question of how relative URLs should be treated. The options I see are:
a) relative URLs are always assumed to be part of the web application
b) relative URLs are always relative the current HttpServletRequest
c) container specific
d) something else

My current expectation is that b) is the intended behaviour and that it was not explicitly stated since it was viewed as the only possible option. It would be helpful of this expectation could be confirmed or denied and either way if a clarification could be added to the Javadoc for 3.1 onwards (and earlier versions where possible).

Note the same issue exists for encodeRedirectURL()

This question was triggered by https://issues.apache.org/bugzilla/show_bug.cgi?id=53469



 Comments   
Comment by Shing Wai Chan [ 09/Feb/13 ]

Since the #encodeURL string may be used later, we may like to keep it as relative, too.
For #encodeRedirectURL, I expect (b), too.

Comment by markt_asf [ 09/Feb/13 ]

That works for me. If some language can be added that relative URLs passed to encodeURL() and encodeRedirectURL() are relative to the current request that would be great.

Generated at Sun Sep 25 17:24:10 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.