I always have the feeling that our map() method does too much magic, especially the prepending of the context path is too much imho.
Anyways, for the issue at hand, yes, I think we should change SlingHttpServletResponseImpl to not add the context path in front. I think this can safely be done by comparing the beginning of the passed in path with the one returned from the map method. So the implementation can know whether the context path has been added again by map() or not. Carsten 2014-04-01 20:24 GMT+02:00 Justin Edelson <[email protected]>: > 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 > -- Carsten Ziegeler [email protected]
