[jira] [Commented] (SLING-3504) SlingHttpServletResponseImpl.encodeXXX methods always add context path

["Carsten Ziegeler (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SLING-3504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13972654#comment-13972654 ] 

Carsten Ziegeler commented on SLING-3504:
-----------------------------------------

I've committed a potential fix according to the suggested implementation mentioned by Justin

> 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)