You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Carsten Ziegeler (JIRA)" <ji...@apache.org> on 2014/04/17 10:53:16 UTC

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

Carsten Ziegeler created SLING-3504:
---------------------------------------

             Summary: 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.2, Engine 2.3.0
            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)