Home > Archive > Unix Programming > March 2008 > how to convert //foo/bar to URI?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
how to convert //foo/bar to URI?
|
|
| Kalle Olavi Niemitalo 2008-03-11, 8:13 am |
| If I understand correctly, SUSv3 says that the meaning of a
pathname is implementation-defined if it begins with exactly two
slashes. Which operating systems use such pathnames?
Is there a customary way of representing such pathnames in URIs?
For example, would //foo/dir/file.html be translated to:
(a) file://localhost//foo/dir/file.html
(b) file://localhost/%2Ffoo/dir/file.html
(c) file://localhost/%2Ffoo%2Fdir%2Ffile.html
The choice of course affects how a ".." reference in file.html
would be handled. So, it should preferably correspond to how the
operating system treats such references. E.g. whether
//foo/../bar means /bar or //bar or something entirely different.
In ELinks, a test related to this is failing, and I'd like to
know what the correct behaviour is before I go tweak the code
again.
| |
| Barry Margolin 2008-03-11, 10:16 pm |
| In article <yw1xabl5d4p9.fsf@thrashbarg.mansr.com>,
Måns Rullgård <mans@mansr.com> wrote:
> Kalle Olavi Niemitalo <kon@iki.fi> writes:
>
>
> Microsoft Windows, possibly others.
I vaguely recall some early network filesystem implementations that used
this, something like //servername/path/to/file. Maybe this was on
Apollo workstations?
>
>
> Since the meaning of // is implementation-defined, there cannot be a
> single correct behaviour.
Sure there can. He's just asking about a syntactic transformation from
URL to pathname, regardless of how the pathname will be interpreted by
the OS. This should be specified in the description of the file: URL
scheme.
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
| |
| Måns Rullgård 2008-03-11, 10:16 pm |
| Barry Margolin <barmar@alum.mit.edu> writes:
> In article <yw1xabl5d4p9.fsf@thrashbarg.mansr.com>,
> Måns Rullgård <mans@mansr.com> wrote:
>
>
> I vaguely recall some early network filesystem implementations that used
> this, something like //servername/path/to/file. Maybe this was on
> Apollo workstations?
>
>
> Sure there can. He's just asking about a syntactic transformation from
> URL to pathname, regardless of how the pathname will be interpreted by
> the OS. This should be specified in the description of the file: URL
> scheme.
What if the implementation-defined meaning of // is for //foo/bar/baz
to be equivalent to http://foo/bar/baz, or anything else that cannot
be represented by a file: URL?
--
Måns Rullgård
mans@mansr.com
| |
| Barry Margolin 2008-03-11, 10:16 pm |
| In article <yw1xy78patos.fsf@thrashbarg.mansr.com>,
Måns Rullgård <mans@mansr.com> wrote:
> Barry Margolin <barmar@alum.mit.edu> writes:
>
>
> What if the implementation-defined meaning of // is for //foo/bar/baz
> to be equivalent to http://foo/bar/baz, or anything else that cannot
> be represented by a file: URL?
I don't see a problem with that. That equivalence would be implemented
behind the scenes in the OS. So you type something like
file://localhost//foo/bar/baz into the browser, the browser calls
open("//foo/bar/baz", O_RDONLY), the OS does whatever
implementation-defined thing it wants.
The OP's question was whether file://localhost//foo/bar/baz is the
correct transformation of such a pathname to a URI. The file: scheme is
described in RFC 1738, but I think it leaves much to be desired. It
only gives one example, and it doesn't really match the description. It
says the form is file://host/directory/directory/.../name, but the
example it then gives is of a VMS pathname, where the first component is
a device, not a directory: DISK$USER:[MY.NOTES]NOTE123456.TXT ->
file://vms.host.edu/disk$user/my/notes/note123456.txt. Also, note that
common practice on DOS/Windows implementations is to include the ":"
following a device name in the URL, e.g. C:\dir1\dir2\file.txt ->
file:///C:/dir1/dir2/file.txt.
Since URIs look so much like Unix pathnames, in this case I would expect
most implementations to simply strip off the file://localhost prefix,
convert any % codes to the corresponding character, and pass the result
to the open() system call. So I think any of the OP's translations
would work equivalently.
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
| |
| Kalle Olavi Niemitalo 2008-03-12, 7:31 pm |
| Måns Rullgård <mans@mansr.com> writes:
> Since the meaning of // is implementation-defined, there cannot be a
> single correct behaviour.
I can implement different filename-to-URI mappings on different
operating systems if I know the local semantics and how to detect
the operating systems at configure or run time. My intention is
that relative URI-references would behave the same as relative
pathnames.
So far, Windows and Apollo workstations have been mentioned.
On those, do pathnames in the "//" namespace use "/" as a
directory separator and ".." to mean the parent directory?
Is "//foo/.." the same as "//" and "//.." the same as "/"?
Is there any syntax that would make "/" not have its usual
meaning? (E.g. "@" in "//versioned/dir/file@03/13/2008".)
|
|
|
|
|