[XML-SIG] file urls in urllib

[Martin v. Loewis]

> what is bothering me is that assembly of a url from its
> scheme,net_loc,path components (or parsing a url into those
> components) would seemingly have to know about the server OS, just
> to know what to do with host-path separator slash, which is
> sometimes significant and sometimes not.

It is, in general, not possible to interpret the file: URL on another
but the local system. In fact, I cannot think of a single system where
it *is* possible.

> on the client, suppose i am given a server-specific host path
> (c:\autoexec.bat or /etc/passwd)

Not sure what the client and the server is here.

> and want to make a url. so i follow the rule
>    C1. if the path starts with /, prepend file://
>    C2. else prepend file:///

No. On DOS, build a list of components, starting with drive,
directory, ... On Unix, build a list of components, starting with
directory, directory, ... Then join the components with slashes. Put
your machine name in front of it if you want, or else leave it blank.

If you meant to take the local filename literally, it would not work
if the file name uses characters that are reserved in URLs.

> on the server, suppose i am given a file: url. So i follow these rules:
>    S1. if there are exactly 0 or 1 slashes after file:, remove file: and take the rest to be the path, possibly relative
>    S2. else if there are exactly 2 slashes after file:, error
>    S3. else if there are 3 or more slashes after file:, remove file:/// and consider the remainder:
>       a. if the remainder starts with a system-specific file system root (such as / or c: or c| or \\), use the string as the
> absolute path
>       b. else prepend "/" and use that string as the absolute path
> 
> would that work?

No. For Windows NT and Unix, it would probably work. On the Mac, it
probably wouldn't - you'll have to replace slashes in the path with
colons. On VMS, using the example from the RFC, it probably would fail
as well.

Regards,
Martin