Hi Alex, TBH, when looking at SLING-3338, I didn't even consider whether or not encodeURL and encodeRedirectURL *should* actually do path mapping. I was only concerned with the fact that the mapping it did do (which was there for 6+ years) was wrong in multi-domain setups.
I would be curious if anyone remembers why these methods call map() in the first place. Regarding c:url, my understanding is that it is supposed to result in the the Java SessionID being appended (depending on configuration) and so rightly uses encodeURL. Justin On Tue, Apr 1, 2014 at 4:06 PM, Alexander Klimetschek <[email protected]> wrote: > 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 >
