Hi Carsten, Just curious - why do you prefer to remove the context path from the *result* of ResourceResolver.map() rather than removing it from the path passed *to* ResourceResolver.map()?
Since ResourceResolver.map() does a resolve() call, it seems to make more sense to me that the path passed into it is the real resource path, not the context path + resource path. Regards, Justin On Wed, Apr 2, 2014 at 12:54 AM, Carsten Ziegeler <[email protected]> wrote: > 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]
