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 <r...@apache.org> wrote: > Hi Dan, > > > On 19 Nov 2019, at 16:18, Daniel Klco <dk...@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>
