You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Nathaniel Alfred <Al...@swx.com> on 2003/07/07 22:55:28 UTC
SourceResolver in M3 and symbolic links
The latest version of excalibur.source.SourceResolver packaged
with Cocoon-2.1m3 normalizes URIs containing "/foo/../bar" to "/bar".
At first sight this looks a good idea and is according to RFC 2396.
But when dealing with file: URIs foo can be a symbolic link
(aka short-cut) such as "foo -> some/where/else". Following
filesystem semantics, "/foo/../bar" results in "/some/where/bar".
Used with care this can be a powerful feature, which got lost now.
(My setup is currently royally screwed due to that.)
So is file:/foo/../bar going to stay a URI as per RFC 2396, or shall
we have an exception to suppress the "<segment>/.." normalization
step for file:.
Cheers, Alfred.
This message is for the named person's use only. It may contain
confidential, proprietary or legally privileged information. No
confidentiality or privilege is waived or lost by any mistransmission.
If you receive this message in error, please notify the sender urgently
and then immediately delete the message and any copies of it from your
system. Please also immediately destroy any hardcopies of the message.
You must not, directly or indirectly, use, disclose, distribute, print,
or copy any part of this message if you are not the intended recipient.
The sender's company reserves the right to monitor all e-mail
communications through their networks. Any views expressed in this
message are those of the individual sender, except where the message
states otherwise and the sender is authorised to state them to be the
views of the sender's company.
Re: SourceResolver in M3 and symbolic links
Posted by Bruno Dumon <br...@outerthought.org>.
On Tue, 2003-07-08 at 09:56, Bruno Dumon wrote:
> On Mon, 2003-07-07 at 22:55, Nathaniel Alfred wrote:
> > The latest version of excalibur.source.SourceResolver packaged
> > with Cocoon-2.1m3 normalizes URIs containing "/foo/../bar" to "/bar".
> > At first sight this looks a good idea and is according to RFC 2396.
> >
> > But when dealing with file: URIs foo can be a symbolic link
> > (aka short-cut) such as "foo -> some/where/else". Following
> > filesystem semantics, "/foo/../bar" results in "/some/where/bar".
> > Used with care this can be a powerful feature, which got lost now.
> > (My setup is currently royally screwed due to that.)
> >
> > So is file:/foo/../bar going to stay a URI as per RFC 2396, or shall
> > we have an exception to suppress the "<segment>/.." normalization
> > step for file:.
>
> Technically it's no problem to restore the previous behaviour for the
> file: scheme. I didn't think of the above use case. I'll look into
> fixing it and let you now when it's done.
Ah, I see you have already a patch submitted to Avalon...
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
Re: SourceResolver in M3 and symbolic links
Posted by Bruno Dumon <br...@outerthought.org>.
On Mon, 2003-07-07 at 22:55, Nathaniel Alfred wrote:
> The latest version of excalibur.source.SourceResolver packaged
> with Cocoon-2.1m3 normalizes URIs containing "/foo/../bar" to "/bar".
> At first sight this looks a good idea and is according to RFC 2396.
>
> But when dealing with file: URIs foo can be a symbolic link
> (aka short-cut) such as "foo -> some/where/else". Following
> filesystem semantics, "/foo/../bar" results in "/some/where/bar".
> Used with care this can be a powerful feature, which got lost now.
> (My setup is currently royally screwed due to that.)
>
> So is file:/foo/../bar going to stay a URI as per RFC 2396, or shall
> we have an exception to suppress the "<segment>/.." normalization
> step for file:.
Technically it's no problem to restore the previous behaviour for the
file: scheme. I didn't think of the above use case. I'll look into
fixing it and let you now when it's done.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org