(In reply to comment #0)
> 
> File URLs require an extra '/'.
> 'file:///abs_path/file_name' is failing to refer to '/abs_path/file_name' in a
> POSIX file system, 'file:////abs_path/file_name' is referring to it

I thought that both file:///abs_path/file_name and file:/abs_path/file_name
were valid URIs, but that file://abs_path/file_name and
file:////abs_path/file_name were not.

It is not clear to me what you want.  Current jglobus has:

file:///path/file

refer to: path/file, and:

file:////path/file

refer to /path/file.  

From the the RFC that you posted this seems correct.  3 slashes are needed, 2
for the scheme seperator :// and then 1 for the empty host separator, from
there you start the path.  Sure it is quite a bit of slashes and i imagine that
it why there are so many other convention for file urls, but i think it is
complaint.  Is there some optional or additional behavior that you are looking
for?

I think Marco's point is that the RFC mentions that "/" is a separator if
present before the path and that it should not be considered meaningful beyond
that, and that all paths, whether prefixed with a slash or not should be
absolute. Also the FTP URL RFC mentions that an absolute path should be
prefixed with %2f (presumably if the default ftp dir is different from the root
of the FS).

E.g. 
file:///etc/passwd should point to /etc/passwd.
ftp://host/etc/passwd should point to FTP_ROOT/etc/passwd
ftp://host/%2fetc/passwd should point to /etc/passwd

This is somewhat tricky because it makes it more difficult to express "relative
paths" in a uniform way, something that seems not to have been considered much
in the RFCs.

It is difficult to make a change to this parsing code after cog has existed for
so long.  Does anyone know the conventions or assumptions most users make?  We
could overload the parsing functions such that a new method includes a flag
specifying file url parsing behavior, would that work for your situation?