[XML-SIG] file urls in urllib

[Mark D. Anderson]

> A different parser is used on Windows and Unix, so file:///etc/passwd
> could mean different things on Windows and Unix. On Windows, it might
> be ill-formed: for an absolute path, you need a drive letter (or else
> you need to learn the current drive based on some magic processing
> context); or it could mean \\etc\passwd (i.e. etc being the topmost
> hierarchy level, if you allow file: URLs to denote UNC names). On
> Unix, it clearly means /etc/passwd.

it is certainly the case that interpretation of the path portion is server-specific.

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.

but maybe it is all ok....

on the client, suppose i am given a server-specific host path (c:\autoexec.bat or /etc/passwd)
and want to make a url. so i follow the rule
   C1. if the path starts with /, prepend file://
   C2. else prepend file:///

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?
note that this treats backward slashes like any other character.
server rule S1 is to allow the convenience of just prepending "file:" in front of anything, although
clients obeying the client rules above would never do that.
it also introduces a (non-rfc) convention for sending a relative file url.

-mda