[plt-scheme] Re: file: urls & their relation to path names

From: Robby Findler (robby at cs.uchicago.edu)
Date: Fri Jan 6 21:49:36 EST 2006

After poking around on the web a little bit, I found this:


which suggests that the url for, say, /etc/hosts on my machine should  


which seems to be in contradiction with the very beginning of  
rfc3986, which says: "...refers to a file on the end-user's file  
system (e.g., 'file:///etc/hosts')." Given the context of the rfc  
quote, however, I'm inclined to think that is a bug in the rfc and  
assume that the url should be as above.


On Jan 6, 2006, at 8:29 PM, Robby Findler wrote:

> It looks like there is a little bit of under-specification (or maybe a
> mistake?) in rfc 3986 about dealing with file: urls. For example,
> should the path:
>   /home/robby/tmp.ss
> be represented in the file: url as:
>   file:///%3f/home/robby/tmp.ss
> or as:
>   file:///home/robby/tmp.ss
> ?
> That is, should the first path element (namely the path that
> corresponds to the root of the filesystem, aka (build-path "/"))
> quoted as a special path in the file: url, or not.
> If not, what does that / correspond to on filesystems where the  
> root is
> not "/", like windows? Should the file: url that points to the file
> "tmp.txt" in the c: drive be:
>   file:///c:/tmp.txt
> That is, should it have a forward slash ala the rfc to indicate
> "separate path segments here" or should it have the backwards slash
> like this:
>   file:///c:\tmp.txt
> which would, as far as the url is concerned, be treated as a file: url
> with only a single path element "c:\\tmp.txt".
> I think I'm going to go with the somewhat hackish behavior of
> specialcasing the first path segment and, if it is "/" I'll just drop
> it, but otherwise split of the path into the its segments from
> mzscheme's point of view and then put them together wish "/"s in
> between.
>   file:///home/robby/tmp.ss
>   file://c:/tmp.txt
> (This change will also affect how call/input-url works for file:  
> urls.)
> Robby

Posted on the users mailing list.