file vs http scheme on local intranet

[James Owens]

I maintain a small web page for internal company use. People access it
by typing "library" in their browser address bar; this defaults to
"http://library" which the network admin magically redirects to my page.

Lately some other departments have been creating their own web pages and I
have added links to them. The pages are on the same server, but different
folders (traversing the root folder). These bright young people have
introduced attractive graphics and javascript to their pages. However,
they have also used the file:// scheme for their links. These links
won't work from my page unless I use the file:// scheme to open it.

After much trouble I've learned that file:// references are ignored by
design on pages that have been loaded via http://. The question now is
whether to revamp all our internal pages to use the file:// scheme, or to
standardize on the http:// scheme throughout.

I know that one of the advantages of http:// is that we can later add
server-side search capabilities, cgi scripts, and so on. But I don't know
anything about the advantages of the file:// scheme in a local intranet. I
assume these bright young students (who have since completed their work
term and left the company) had a good reason for using file:// references.

Can anyone offer me some guidance about this?

--
"For it is only of the new one grows tired. Of the old one never tires."
-- Kierkegaard, _Repetition_

James Owens, Ottawa, Canada

[Nick Kew]

In article <c9**********@freenet9.carleton.ca>,
ad***@FreeNet.Carleton.CA (James Owens) writes:

After much trouble I've learned that file:// references are ignored by
design on pages that have been loaded via http://. The question now is
Nope. Just that they don't exist, unless by coincidence. The file://
scheme gives you your own filesystem, and nothing else.
whether to revamp all our internal pages to use the file:// scheme, or to
That might just work if you only have one filesystem in your organisation -
perhaps if all your users are on 'thin clients'. But it can't scale to,
say, two PCs.
standardize on the http:// scheme throughout.
That will scale as much as you need it to.
term and left the company) had a good reason for using file:// references.
Depends whether you consider ignorance "a good reason". Or maybe company
policy precluded them running a server, and the pages were only ever
intended for personal use.
Can anyone offer me some guidance about this?

You could use mod_proxy_html to rewrite your file:// URLs to http on
the fly, so they become visible from other machines. This'll also
enable you to extend it if you ever want to publish some of your
material to the Web, or enable your staff to work from home.

--
Nick Kew

Nick's manifesto: http://www.htmlhelp.com/~nick/

[Jukka K. Korpela]

ad***@FreeNet.Carleton.CA (James Owens) wrote:

These bright young
people have introduced attractive graphics and javascript to their
pages. However, they have also used the file:// scheme for their
links.
Whether such links works is external to HTML, to WWW, and to the
Internet. The file: scheme is by definion system-specific, see
http://www.cs.tut.fi/~jkorpela/fileurl.html
These links won't work from my page unless I use the file://
scheme to open it.
I have no idea of what that refers to. But maybe the file: URLs don't
even comply with the defined syntax.
After much trouble I've learned that file:// references are ignored
by design on pages that have been loaded via http://.
Maybe the references are of incorrect format and thereby interpreted as
relative URLs of some kind.
But I don't
know anything about the advantages of the file:// scheme in a local
intranet.
Neither do I. Well, you can use them without setting up an HTTP server,
but this is more of a problem than a solution,
I assume these bright young students (who have since
completed their work term and left the company) had a good reason for
using file:// references.

They probably just didn't know what they were doing, and they worked on
the "but it works!" (on my system) basis.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

[Stan Brown]

"Nick Kew" <ni**@hugin.webthing.com> wrote in
comp.infosystems.www.authoring.html:

In article <c9**********@freenet9.carleton.ca>,
ad***@FreeNet.Carleton.CA (James Owens) writes:

After much trouble I've learned that file:// references are ignored by
design on pages that have been loaded via http://. The question now is

Nope. Just that they don't exist, unless by coincidence. The file://
scheme gives you your own filesystem, and nothing else.

I'm not 100% certain, but I believe I remember reading that at least
Mozilla won't honor file:// linkls in a documet that was reached by
http://, to prevent a remote page from executing a program on the
visitor's computer.

--
Stan Brown, Oak Road Systems, Cortland County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2 spec: http://www.w3.org/TR/REC-CSS2/
2.1 changes: http://www.w3.org/TR/CSS21/changes.html
validator: http://jigsaw.w3.org/css-validator/

[Stan Brown]

"James Owens" <ad***@FreeNet.Carleton.CA> wrote in
comp.infosystems.www.authoring.html:

I know that one of the advantages of http:// is that we can later add
server-side search capabilities, cgi scripts, and so on. But I don't know
anything about the advantages of the file:// scheme in a local intranet.
If your intranet is running a Web server -- which obviously it is
since http:// references are working -- then I don't think file://
offers any particular advantage.

The only advantage I can think of for file:// is if you want to burn
your local site to a CD-ROM and give or take it to a client or
potential client for a demo -- you could count on it working in
their browser without their having an HTTP server running.
I
assume these bright young students (who have since completed their work
term and left the company) had a good reason for using file:// references.

Perhaps they didn't realize that there was an HTTP server on the
network.

Whichever way you do it, make sure that all references from one page
to another are by _relative_ URLs. That maintains flexibility for
the future.

--
Stan Brown, Oak Road Systems, Cortland County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2 spec: http://www.w3.org/TR/REC-CSS2/
2.1 changes: http://www.w3.org/TR/CSS21/changes.html
validator: http://jigsaw.w3.org/css-validator/

[Jukka K. Korpela]

Stan Brown <th************@fastmail.fm> wrote:

I'm not 100% certain, but I believe I remember reading that at least
Mozilla won't honor file:// linkls in a documet that was reached by
http://, to prevent a remote page from executing a program on the
visitor's computer.

I can confirm this at least for Mozilla Firefox. Clicking on a file://
link causes nothing when the page's own URL is an http:// URL (but works,
to the extent file:// URLs work at all, on local pages).

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

[James Owens]

"Jukka K. Korpela" (jk******@cs.tut.fi) writes:

Stan Brown <th************@fastmail.fm> wrote:

I'm not 100% certain, but I believe I remember reading that at least
Mozilla won't honor file:// linkls in a documet that was reached by
http://, to prevent a remote page from executing a program on the
visitor's computer.

I can confirm this at least for Mozilla Firefox. Clicking on a file://
link causes nothing when the page's own URL is an http:// URL (but works,
to the extent file:// URLs work at all, on local pages).

My source was a Mozilla document:

http://www.mozilla.org/quality/netwo...filetests.html

"Testing file URLs is complicated by the the checkloadURI feature, which
disables file: URLs in network served (http: and https:) pages."

Thanks to all, this will help me persuade the other web page authors to
standardize on http.

--
"For it is only of the new one grows tired. Of the old one never tires."
-- Kierkegaard, _Repetition_

James Owens, Ottawa, Canada