file:///c:/nxdist/tut/tutorials.html or file:c:/nxdist/tut/tutorials.html?

file:///c:/nxdist/tut/tutorials.html or file:c:/nxdist/tut/tutorials.html?

[Lennart Borgman]

The first form is used by Firefox, the second by Emacs.

Are both correct, or?

Re: file:///c:/nxdist/tut/tutorials.html or file:c:/nxdist/tut/tutorials.html?

[Davis Herring]

> The first form is used by Firefox, the second by Emacs.
>
> Are both correct, or?

http://www.ietf.org/rfc/rfc1738.txt says that the file URL scheme looks
like file://host/path, where host may be empty to indicate localhost.  But
http://www.ietf.org/rfc/rfc1808.txt says that you can have a relative
file: URL (a "generic-RL") that just looks like file:path, although it
says that the use of schemes with relative URLs is discouraged.  And on
Windows, the leading slash is not needed to tell whether a path is
absolute or not because of the special status of the drive-letter-colon
names.

So... I think the first one is better, but it's not clear (to me) that the
second is wrong.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: file:///c:/nxdist/tut/tutorials.html or file:c:/nxdist/tut/tutorials.html?

[Lennart Borgman]

On Thu, Jul 23, 2009 at 1:19 AM, Davis Herring<herring@lanl.gov> wrote:
>> The first form is used by Firefox, the second by Emacs.
>>
>> Are both correct, or?
>
> http://www.ietf.org/rfc/rfc1738.txt says that the file URL scheme looks
> like file://host/path, where host may be empty to indicate localhost.  But
> http://www.ietf.org/rfc/rfc1808.txt says that you can have a relative
> file: URL (a "generic-RL") that just looks like file:path, although it
> says that the use of schemes with relative URLs is discouraged.  And on
> Windows, the leading slash is not needed to tell whether a path is
> absolute or not because of the special status of the drive-letter-colon
> names.
>
> So... I think the first one is better, but it's not clear (to me) that the
> second is wrong.

Thanks. I also think the first form is a bit better since

1) It is used by at least Firefox. They are big in this area...
2) It may be slightly easier to handle since it is more like http:// etc.

So I propose we change this.

Re: file:///c:/nxdist/tut/tutorials.html or file:c:/nxdist/tut/tutorials.html?

[Stephen J. Turnbull]

Lennart Borgman writes:
 > On Thu, Jul 23, 2009 at 1:19 AM, Davis Herring<herring@lanl.gov> wrote:
 > >> The first form is used by Firefox, the second by Emacs.
 > >>
 > >> Are both correct, or?
 > >
 > > http://www.ietf.org/rfc/rfc1738.txt says that the file URL scheme looks
 > > like file://host/path, where host may be empty to indicate localhost.  But
 > > http://www.ietf.org/rfc/rfc1808.txt says that you can have a relative

Please refer to RFC 3986; it obsoletes 2396 (which updated both 1738
and 1808) and 1808, updates 1738, and is in fact also STD 66, which
gives you some idea of the importance of and general consensus on the
updates involved (STD 11 is *still* RFC 822, despite the subsequent
acceptance of both RFC 2822 and RFC 5322 as PROPOSED STANDARD and
DRAFT STANDARD respectively!)

Re: file:///c:/nxdist/tut/tutorials.html or file:c:/nxdist/tut/tutorials.html?

[Lennart Borgman]

On Thu, Jul 23, 2009 at 5:17 AM, Stephen J. Turnbull<stephen@xemacs.org> wrote:
> Lennart Borgman writes:
>  > On Thu, Jul 23, 2009 at 1:19 AM, Davis Herring<herring@lanl.gov> wrote:
>  > >> The first form is used by Firefox, the second by Emacs.
>  > >>
>  > >> Are both correct, or?
>  > >
>  > > http://www.ietf.org/rfc/rfc1738.txt says that the file URL scheme looks
>  > > like file://host/path, where host may be empty to indicate localhost.  But
>  > > http://www.ietf.org/rfc/rfc1808.txt says that you can have a relative
>
> Please refer to RFC 3986; it obsoletes 2396 (which updated both 1738
> and 1808) and 1808, updates 1738, and is in fact also STD 66, which
> gives you some idea of the importance of and general consensus on the
> updates involved (STD 11 is *still* RFC 822, despite the subsequent
> acceptance of both RFC 2822 and RFC 5322 as PROPOSED STANDARD and
> DRAFT STANDARD respectively!)

I found it impossible to read. I took a quick look at 3986 and it says

  Use of the slash character
   to indicate hierarchy is only required when a URI will be used as the
   context for relative references.  For example, the URI
   <mailto:fred@example.com> has a path of "fred@example.com", whereas
   the URI <foo://info.example.com?fred> has an empty path.

So I can write

   mailto://fred@example.com

but I can't write

  file:c:/my/path/to/my/file.txt

since the latter (or at least part of it) can be used for relative references.

Or, should I read another part of that document instead... ;-)

Re: file:///c:/nxdist/tut/tutorials.html or file:c:/nxdist/tut/tutorials.html?

[Stephen J. Turnbull]

Lennart Borgman writes:

 > I found it impossible to read. I took a quick look at 3986

OK, I'll read it for you.  RFC 3986 no longer defines any URI schemes,
unlike RFC 1738 which did define the file URI (among others).  From
Section 8, they are registered with the IANA.  Looking at the IANA
registry

    http://www.iana.org/assignments/uri-schemes.html

in fact RFC 1738 still defines the file URI, as follows:

   A file URL takes the form:

       file://<host>/<path>

   where <host> is the fully qualified domain name of the system on
   which the <path> is accessible, and <path> is a hierarchical
   directory path of the form <directory>/<directory>/.../<name>.

   As a special case, <host> can be the string "localhost" or the
   empty string; this is interpreted as `the machine from which the
   URL is being interpreted'.

"file:c:/nxdist/tut/tutorials.html" doesn't satisfy this definition;
the "//" that introduces the host component may not be omitted.

Section 4.2: The ABNF shows that a relative reference does not contain
a scheme.  "file:c:/nxdist/tut/tutorials.html" doesn't satisfy this
definition, either.

Conclusion: "file:c:/nxdist/tut/tutorials.html" is not a URI.

Re: file:///c:/nxdist/tut/tutorials.html or file:c:/nxdist/tut/tutorials.html?

[Lennart Borgman]

On Thu, Jul 23, 2009 at 8:59 AM, Stephen J. Turnbull<stephen@xemacs.org> wrote:
> Lennart Borgman writes:
>
>  > I found it impossible to read. I took a quick look at 3986
>
> OK, I'll read it for you.  RFC 3986 no longer defines any URI schemes,
> unlike RFC 1738 which did define the file URI (among others).  From
> Section 8, they are registered with the IANA.  Looking at the IANA
> registry
>
>    http://www.iana.org/assignments/uri-schemes.html
>
> in fact RFC 1738 still defines the file URI, as follows:
>
>   A file URL takes the form:
>
>       file://<host>/<path>
>
>   where <host> is the fully qualified domain name of the system on
>   which the <path> is accessible, and <path> is a hierarchical
>   directory path of the form <directory>/<directory>/.../<name>.
>
>   As a special case, <host> can be the string "localhost" or the
>   empty string; this is interpreted as `the machine from which the
>   URL is being interpreted'.
>
> "file:c:/nxdist/tut/tutorials.html" doesn't satisfy this definition;
> the "//" that introduces the host component may not be omitted.
>
> Section 4.2: The ABNF shows that a relative reference does not contain
> a scheme.  "file:c:/nxdist/tut/tutorials.html" doesn't satisfy this
> definition, either.
>
> Conclusion: "file:c:/nxdist/tut/tutorials.html" is not a URI.


Thanks. So then there is a bug in browse-url-file-url. It return URI:s
like file:c:/nxdist/tutorial.html.

 I suggest we fix it.

Re: file:///c:/nxdist/tut/tutorials.html or file:c:/nxdist/tut/tutorials.html?

[Davis Herring]

> in fact RFC 1738 still defines the file URI, as follows:

I find it amusing that I accidentally looked at the right RFC and gave the
right answer (even if I then did go off to RFC 1808 irrelevantly).  Thanks
for straightening it out; I should have remembered to look for URI instead
of URL in the beginning.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.