Re: File URIs, home and relative paths

On Wed, 8 Jun 2016 at 04:42 Matthew Kerwin <matthew@kerwin.net.au> wrote:

> On 08/06/2016 2:50 PM, "Julian Reschke" <julian.reschke@gmx.de> wrote:
> >
> > On 2016-06-08 01:39, Jason Dusek wrote:
> >>
> >> Dear List,
> >>
> >> The use of HTTP and other recognized URL schemes for resource
> >> identification often overlaps with the use of files. For example, in the
> >> specification of Python dependencies.
> >> ...
> >
> >
> > Time to review <
> https://tools.ietf.org/html/draft-ietf-appsawg-file-scheme-10>, I guess
> :-)
> >
> > Best regards, Julian
> >
>
> ​​
> ​I'm definitely taking Jason's comments on board, but I can't see anyone
> implementing this.  In the case of the draft, my goal is updating the
> scheme to fit with RFC 3986 and documenting the funny things people already
> do, not inventing new things.
>
> ​Here are my thoughts on the proposal:
>
> 1. '.' already means something in URIs; you can't redefine it, even for
> just one scheme, without rewriting RFC 3986 (possibly requiring a time
> machine.)  Since '.' is an unreserved character we can't even use "%2E" to
> smuggle it through the remove_dot_segments algorithm.
>
This is a fair point. I don’t think direct use of . is viable; it has to be
by way of some indirection.

> 2. Presumably the proposed '~' and '.' are only special when they're the
> first path segment*.  How would that interact with relative resolution?  To
> me, as someone familiar with tilde expansion in bash, I'd expect
> "~/foo/bar" to be an obvious relative reference, but if it were resolved
> against a base URL with subdirectories in the path, the tilde would find
> itself above the root, and thus lose all its special meaning.  We'd have to
> use "/~/foo/bar" as the relative reference, which is unintuitive and kind
> of counter to the proposal.
>
>  * otherwise what would "/foo/~/bar" mean?
>
> 3. This would break: `mkdir -p /\~/foo ; touch /\~/foo/bar`
>  ("file:///~/foo/bar" would always resolve to my home directory;
> "file:///%7E/foo/bar" would too, since '~' is unreserved)
>
Fair points.

In the draft RFC, some allowance is made for UNC paths, which result in
runs of slashes like this file://///... UNC provides a notion of a share
and perhaps we could treat home, dot and dot dot as shares? Using
file://..././/.., file://.../~//..., &c.

Another possibility is to make use of a reserved character, the @, as a
mysterium bonum. We imagine a virtual directory at file:///@ wherein:

   - file:///@/. is a link to the present directory as defined by the end
   user’s context,
   - file:///@/.. is the directory above this directory,
   - file:///@/~ is the end user’s home directory.

To access a file or directory @ at the system root, one can use file:///%40.
Is this something that a conforming implementation could provide under the
present draft?
Kind Regards,
  Jason Dusek


>
> Off-list I suggested Jason use RFC 6570 URI templates, and define
> variables like {+PWD} or {+HOME} in the context of his application (even
> though "moustache templates" aren't aesthetically pleasing).  I still think
> that's probably the best way forward.
>
> Cheers,
> Matty
>
>