file: urls and Firebird
-
- Posts: 49
- Joined: June 19th, 2003, 10:19 am
file: urls and Firebird
With Firebird 0.6, I am unable to use file: urls except for file://<drive>: and file://<drive>|
Trying to bring up files with:
file://share/folder/filename
does absolutely nothing -- no error messages or anything!
My build is:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030516 Mozilla Firebird/0.6
Trying to bring up files with:
file://share/folder/filename
does absolutely nothing -- no error messages or anything!
My build is:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030516 Mozilla Firebird/0.6
- iarnell
- Posts: 784
- Joined: February 1st, 2003, 4:26 pm
- Location: Netherlands
- Contact:
-
- Posts: 49
- Joined: June 19th, 2003, 10:19 am
Blobber wrote:Yes, five "/" works! Unfortunately it's non-standard. Firebird doesn't even pass Mozilla's own tests on this one. We make extensive use of the standard format on our intranet. Hopefully a later build will address the problem.
See:
http://www.mozilla.org/quality/networki ... tests.html
-
- Posts: 49
- Joined: June 19th, 2003, 10:19 am
iarnell wrote:And also see bug 38643 - various numbers of /s can cause various kinds of problems. It looks like file:///// is the safest way to get to a UNC.
Yeah, but it doesn't help when viewing web sites coded using the standard form.
Oh well. perhaps another day, on another build.....!
- iarnell
- Posts: 784
- Joined: February 1st, 2003, 4:26 pm
- Location: Netherlands
- Contact:
Define the standard to which you are referring. RFC1738 says file://<host>/<path>, but from comment 36 in that bug
Andreas Otte wrote:The host in the file-url has nothing to do the host in an UNC filepath. As the
name suggests, all of UNC is happening inside the path component of the URL. All
the urlparser can do is guess and add the appropiate number of slashes as
necessary. So to really be an UNC filepath it has to be file://///foo to work on
every OS. Two slashes for the protocol, one to delimit the non existing host and
then two to start the UNC filepath.
-
- Posts: 49
- Joined: June 19th, 2003, 10:19 am
iarnell wrote:Define the standard to which you are referring. RFC1738 says file://<host>/<path>, but from comment 36 in that bugAndreas Otte wrote:The host in the file-url has nothing to do the host in an UNC filepath. As the
name suggests, all of UNC is happening inside the path component of the URL. All
the urlparser can do is guess and add the appropiate number of slashes as
necessary. So to really be an UNC filepath it has to be file://///foo to work on
every OS. Two slashes for the protocol, one to delimit the non existing host and
then two to start the UNC filepath.
I am refering to both RFC1738 and Mozilla's own test suite:
http://www.mozilla.org/quality/networki ... tests.html
In spite of the comment quoted, common usage has supported the simpler form where file://<host>/<path> === file://host/share/subdir... especially on Windows systems. IE works this way. I haven't had a chance to try other browsers yet
- iarnell
- Posts: 784
- Joined: February 1st, 2003, 4:26 pm
- Location: Netherlands
- Contact:
Mozilla's behaviour is correct.
If your machine is called <host>, then you can can access <path> in file://<host>/<path>. You cannot, for example, access file://mozilla.org/index.html (unless your machine happens to be called mozilla.org).
Or, if you want to use UNC, you use the special case where <host> is the empty string (file:///) and you specify the full UNC path like //server/share/<path> giving you file://///<server>/<share>/<path>.
Nowhere on the filetests page does it mention accessing UNC resources.
Just because IE does it differently doesn't make it right. In IE, you can enter C:\AUTOEXEC.BAT and it will find it...
RFC1738 wrote:The file URL scheme is used to designate files accessible on a particular host computer. This scheme, unlike most other URL schemes, does not designate a resource that is universally accessible over the Internet.
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'.
The file URL scheme is unusual in that it does not specify an Internet protocol or access method for such files; as such, its utility in network protocols between hosts is limited.
If your machine is called <host>, then you can can access <path> in file://<host>/<path>. You cannot, for example, access file://mozilla.org/index.html (unless your machine happens to be called mozilla.org).
Or, if you want to use UNC, you use the special case where <host> is the empty string (file:///) and you specify the full UNC path like //server/share/<path> giving you file://///<server>/<share>/<path>.
Nowhere on the filetests page does it mention accessing UNC resources.
Just because IE does it differently doesn't make it right. In IE, you can enter C:\AUTOEXEC.BAT and it will find it...
-
- Posts: 49
- Joined: June 19th, 2003, 10:19 am
well.. the mozilla test suite states:
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>.
3.10
However, if I follow this example in Firebird, with:
file://myfqdn/mydir1/mydir1/filename
nothing happens. My file is not displayed, no external viewer is launched, and no error message is produced.
Something is not right!
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>.
3.10
However, if I follow this example in Firebird, with:
file://myfqdn/mydir1/mydir1/filename
nothing happens. My file is not displayed, no external viewer is launched, and no error message is produced.
Something is not right!
- iarnell
- Posts: 784
- Joined: February 1st, 2003, 4:26 pm
- Location: Netherlands
- Contact:
But the file: protocol does not specify how to get to any machine other than your local host. You can enter file://mozilla.org/index.html and the URL handling mechanism may even recognise that mozilla.org is another computer, but by using file: you don't specify how to get to moziila.org in order to retrieve index.html. (actually, I think Mozilla always ignores the host and collapses file://<host>/<path> to file:///<path>).
That's why rfc 1738 states that "...its utility in network protocols between hosts is limited".
As for file://myfqdn/blah/blah. Assuming that you're on Windows, then you're asking for a file called /blah/blah. But, you must specify the full path to the file which includes the drive letter (notice all those windows examples on your beloved test page that start with file:///c:) - without it, Mozilla won't find what you're looking for. I don't remember where and can't be bothered to look, but if you dig through bugzilla, I'm sure you can find the reason.
That's why rfc 1738 states that "...its utility in network protocols between hosts is limited".
As for file://myfqdn/blah/blah. Assuming that you're on Windows, then you're asking for a file called /blah/blah. But, you must specify the full path to the file which includes the drive letter (notice all those windows examples on your beloved test page that start with file:///c:) - without it, Mozilla won't find what you're looking for. I don't remember where and can't be bothered to look, but if you dig through bugzilla, I'm sure you can find the reason.
-
- Posts: 49
- Joined: June 19th, 2003, 10:19 am
iarnell wrote:But the file: protocol does not specify how to get to any machine other than your local host. You can enter file://mozilla.org/index.html and the URL handling mechanism may even recognise that mozilla.org is another computer, but by using file: you don't specify how to get to moziila.org in order to retrieve index.html. (actually, I think Mozilla always ignores the host and collapses file://<host>/<path> to file:///<path>).
That's why rfc 1738 states that "...its utility in network protocols between hosts is limited".
As for file://myfqdn/blah/blah. Assuming that you're on Windows, then you're asking for a file called /blah/blah. But, you must specify the full path to the file which includes the drive letter (notice all those windows examples on your beloved test page that start with file:///c:) - without it, Mozilla won't find what you're looking for. I don't remember where and can't be bothered to look, but if you dig through bugzilla, I'm sure you can find the reason.
The full path to the file does not need to contain a drive letter. Under Windows, UNC notation is sufficient, thus file://mycomputer/c$/dir will work to get at files in the admin share. Similarly, if I shared my cdrom as "cdrom", file://mycomputer/cdrom will work as well.
If Mozilla (Firebird) simply places a call to the file system for //host/dir/dir/dir, it will work on Windows systems, which know how to resolve the UNC. That's probably why it works fine on IE and Netscape. Why Firebird doesn't work this way is beyond me.