If I read the javadoc for HttpServletResponse.encodeURL() [1] correctly, all it does is to add the Java servlet Session ID. It isn't even supposed to encode anything on the string level - "encode" seems to be used as a term for "include session id" here.
OTOH, this discussion [2] - or better the first comment - mention that it can be used by web frameworks to define whatever a custom mapping/encoding for a URL is. But I think in any case it is weird to add the context path to it, as that is a standard java servlet concept, and if that would be needed here, the javadocs should explicitly mention it. Looking at SLING-3338, the question is what <c:url> is supposed to do and why the org.apache.taglibs.standard.tag.rt.core.UrlTag implementation just relies on encodeUrl. [1] http://docs.oracle.com/javaee/5/api/javax/servlet/http/HttpServletResponse.html#encodeURL(java.lang.String) [2] http://closingbraces.net/2007/02/11/encodeurlandencoderedirecturl/ Cheers, Alex On 01.04.2014, at 11:24, Justin Edelson <[email protected]> wrote: > Hi, > I'm seeing an issue related to ResourceResolver.map(). In the > two-argument version, if the HttpServletRequest object passed has a > context path, that context path is *always* prepended to the mapped > resource path. In SLING-3338[1], I made a change to > SlingHttpServletResponseImpl so that the two-argument map() method was > called. As described in SLING-3338, this was necessary because without > it, the request's domain was not taken into account when determining > the path mapping. > > However, it turns out that this is problematic because the API > contract of HttpServletResponse.encodeURL(String) and > HttpServletResponse.encodeRedirectURL(String) requires that the > context path *not* be prepended. Meaning that callers of these method > typically manually add the context path, i.e > > String url = response.encodeURL(request.getContextPath() + "/foo"); > > The simplest approach I can think of is to add code in > SlingHttpServletResponseImpl to remove the context path from the > parameter passed to encodeURL() and encodeRedirectURL(). This, > however, is potentially problematic as it would fail to handle > correctly the (edge) case where the context path and the first path > segment were the same. > > Does anyone have a better suggestion? > > Regards, > Justin > > > [1] https://issues.apache.org/jira/browse/SLING-3338
