Hi Justin, ah right - got it. Yes, I wasn't thinking that case through...so it seems your suggestion is better than :)
Regards Carsten 2014-04-02 14:51 GMT+02:00 Justin Edelson <[email protected]>: > 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] > -- Carsten Ziegeler [email protected]
