[ https://issues.apache.org/jira/browse/SLING-3504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Carsten Ziegeler resolved SLING-3504. ------------------------------------- Resolution: Fixed > SlingHttpServletResponseImpl.encodeXXX methods always add context path > ---------------------------------------------------------------------- > > Key: SLING-3504 > URL: https://issues.apache.org/jira/browse/SLING-3504 > Project: Sling > Issue Type: Bug > Components: Engine > Affects Versions: Engine 2.3.0, Engine 2.3.2 > Reporter: Carsten Ziegeler > Assignee: Carsten Ziegeler > Fix For: Engine 2.3.4 > > > As posted by Justin in the dev list: > "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." -- This message was sent by Atlassian JIRA (v6.2#6252)