Hi Dan, > On 19 Nov 2019, at 16:18, Daniel Klco <[email protected]> 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>
