sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Radu Cotescu <r...@apache.org>
Subject Re: [org.apache.sling.xss] namespace mangling
Date Tue, 19 Nov 2019 17:03:50 GMT
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