sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Klco <dk...@apache.org>
Subject Re: [org.apache.sling.xss] namespace mangling
Date Wed, 20 Nov 2019 13:26:53 GMT
Makes sense to me! I definitely agree this is unexpected behavior and given
current browser support the risk is low.

On Tue, Nov 19, 2019 at 12:03 PM Radu Cotescu <radu@apache.org> wrote:

> Hi Dan,
>
> > On 19 Nov 2019, at 16:18, Daniel Klco <dklco@apache.org> wrote:
> >
> > I've seen issues with this in the wild. A client was attempting to link
> to
> > external URLs containing colons (bad practice I know, but you get health
> > care web services to get out of the 1990's) in a HTL script which was
> > getting mangled even though the URL was not a JCR path.
>
> Cough… I might have seen this problem last week… Cough...
>
> >
> > My concern is that if this gets removed could the converse become a
> > problem?
>
> Anything can happen, but it doesn’t mean that the API should work like one
> of its implementations and the API definitely doesn’t mention anything
> about JCR namespaces.
>
> > How would implementers know when to mangle the paths correctly
>
> If you refer to developers trying to expose Resource paths as URLs, then
> they should ALWAYS use ResourceResolver#map, since this takes care of not
> only namespace mangling, but also of the mapping configurations. I
> obviously cannot be the one throwing the stone, since I could also be
> guilty of not using the correct mechanism to expose a URL for a Resource,
> but the API has been there for ages (the very beginning of Sling, so 10
> years?!).
>
>
> > and
> > does this place the burden on the end developer to support this and thus
> > potentially lead to errors in the implementation?
> >
>
> I might be too young to have the context why this was needed, but I
> suspect it’s something related to some user agents not being able to cope
> with “:” in the path segment of the URI, although the latest RFC [3]
> definitely allows this and the browsers we use nowadays also have no issues
> any more. At this point I’d strongly argue that it’s not needed any more to
> do any kind of mangling.
>
> Regards,
> Radu
>
> [3] - https://tools.ietf.org/html/rfc3986 <
> https://tools.ietf.org/html/rfc3986>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message