Daniel Stenberg <daniel_at_haxx.se> writes:

> The first slash after the host name is not a part of the path, it is a mere
> separator.
>
> I think this quote from RFC1738 says it pretty clearly:
>
> The rest of the locator consists of data specific to the
> scheme, and is known as the "url-path". It supplies the
> details of how the specified resource can be accessed. Note
> that the "/" between the host (or port) and the url-path is
> NOT part of the url-path.
>
> (section 3.1, page 5)

Ah, I had overlooked this - indeed, the quote is pretty clear.

>> I must admit that from reading RFCs 1738 and 2396, I couldn't tell
>> for sure whether the above URL is correct or whether it should be
>> file://localhost//path/to/file

> Both are valid URLs, but the latter example is an absolute path while the
> first one is a relative path.

sounds reasonable; but what's strange is that libwww (and also browsers
like netscape, lynx or mozilla) *all* seem to treat an url-path with one
`/' after `localhost' as absolute, not as relative path.

> How does libwww treat the path in 'file://localhost/foo' ? as '/foo' ?

Yup; trying to load a relative path with `HTLoadFile' fails:

$ pwd
/home/ulrich
$ ls -l test.txt
-rw-r--r-- 1 ulrich users 16 Aug 5 02:20 test.txt
$ ./wwwtest1
[...]
HTAccess.... Accessing document file://localhost/test.txt
[...]
HTLoadFile.. Looking for `file://localhost/test.txt'
[...]
AutoMulti... can't stat "/test.txt"(errno 2)
[...]
Error fetching `file://localhost/test.txt':
libwww: Fatal Error: 404 Not Found

but using an absolute path with one `/' works:

$ ls ulrich # just to make sure ...
ls: home: No such file or directory
$ ./wwwtest2
[...]
HTAccess.... Accessing document file://localhost/home/ulrich/test.txt
[...]
HTLoadFile.. Looking for `file://localhost/home/ulrich/test.txt'
[...]
Load File... Found `/home/ulrich/test.txt'
[...]
Load End.... OK: `file://localhost/home/ulrich/test.txt'

-- 
Stefan Ulrich