sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Sedding <jsedd...@gmail.com>
Subject Re: [org.apache.sling.xss] namespace mangling
Date Mon, 25 Nov 2019 09:49:43 GMT
IIRC there was at least one other reason for namespace mangling: to
support a filesystem based caching proxy where URLs are mapped to FS
paths. AFAIK windows doesn't allow the colon character in file or
folder names.

Whether that's an architecturally sound implementation choice is of
course another story. I would argue that it would ideally be the
caching proxy that should handle mapping of URLs to valid FS paths.

FWIW, I agree with removing this functionality from XSS, because that
certainly is not the right place for this logic.

Regards
Julian

On Wed, Nov 20, 2019 at 2:27 PM Daniel Klco <dklco@apache.org> wrote:
>
> 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
View raw message