Default dir for file urls.

[Mike.Duffy]

What is the default directory in the client file system that is used for
file urls?

From performing a few experiments, it is clear that an unqualified
reference from another file url is always directed to the source directory.

I.e., from within url "file://c:/abc/def.htm", if you make a reference like
<href="ghi.htm">, or <img src="jkl.gif">,the browser will look for
"file://c:/abc/ghi.htm" or "file://c:/abc/jkl.gif".

But from within url "http://mno.htm", (i.e. a file you put on a web server)
if you use <href="file://ghi.htm">, or <img src="file://jkl.gif">, exactly
where does the browser look for the file? I realize that it would likely be
OS-dependant, but am chiefly interested in the Windows environment. Does it
use one of those user or system environment variables? Or will it always
fail? I have not been able to guess where to put the files in order to
"find" them like this. Does anyone have any suggestions before I take the
systematic approach of placing a watermarked file into every sub-directory
in my filesystem and seeing what comes up? I think I can actually do this
with a small amount of effort using one of those freeware html index
builder programs, but it would probably take a while to run. (And clean up
afterwards!!)

 

[Jukka K. Korpela]

Scripsit Mike.Duffy:

What is the default directory in the client file system that is used
for file urls?

Whatever the browser programmers decided. The detailed syntax and especially
the meaning of file urls is system-dependent, making them almost useless in
WWW authoring. You don't actually see them much on web pages except as
products of wrong use of authoring software that uses them internally
(replacing them by http urls when used properly).

From performing a few experiments, it is clear that an unqualified
reference from another file url is always directed to the source
directory.

That might happen in the browsers you have tested. You have a few hundreds
of millions of other situations to test.

I have not
been able to guess where to put the files in order to "find" them
like this.

Just stop the guesswork and upload the files onto a web server (or other
http server), or - if you're doing this for your own use or very restricted
user range only - use relative references (with no protocol part anywhere)
only.

 

[David E. Ross]

What is the default directory in the client file system that is used for
file urls?

From performing a few experiments, it is clear that an unqualified
reference from another file url is always directed to the source directory.

I.e., from within url "file://c:/abc/def.htm", if you make a reference like
<href="ghi.htm">, or <img src="jkl.gif">,the browser will look for
"file://c:/abc/ghi.htm" or "file://c:/abc/jkl.gif".

But from within url "http://mno.htm", (i.e. a file you put on a web server)
if you use <href="file://ghi.htm">, or <img src="file://jkl.gif">, exactly
where does the browser look for the file? I realize that it would likely be
OS-dependant, but am chiefly interested in the Windows environment. Does it
use one of those user or system environment variables? Or will it always
fail? I have not been able to guess where to put the files in order to
"find" them like this. Does anyone have any suggestions before I take the
systematic approach of placing a watermarked file into every sub-directory
in my filesystem and seeing what comes up? I think I can actually do this
with a small amount of effort using one of those freeware html index
builder programs, but it would probably take a while to run. (And clean up
afterwards!!)

In general, an attempt to access a file from a local file system via a
Web page on a Web server will fail. Most newer browsers will reject the
attempt because allowing this creates a security vulnerability. I think
both IE and the various Mozilla browsers will block the attempt.

--
David E. Ross
<http://www.rossde.com/>

Natural foods can be harmful: Look at all the
people who die of natural causes.

 

[Mike.Duffy]

In general, an attempt to access a file from a local file system via a
Web page on a Web server will fail. Most newer browsers will reject
the attempt

I discovered by trial & error that it does work, (IE6SP1) and the default
is "C:\". The syntax is very specific. On the server, you can put the
full path, i.e. within url

http://index.htm

you can use

<a href="file://C:/Sub_dir/Index.htm">Click Here!</a>

as well, you can use just the file name, but not as expected.


This works:

<a href="file:/Index.htm">Click Here!</a>


but you cannot use:

<a href="file:Index.htm">Click Here!</a>

nor

<a href="file://Index.htm">Click Here!</a>

For unknow reasons, it takes a long time (~30 sec) to fail.


An interesting sidenote is that you can use:

<a href="file://server/share/Index.htm">Click Here!</a>

to access a shared resource.

<img ..> tags work perfectly as well. Note that there is a limit on the
length of the string. The above "full" path works, but not the complete
"My Documents" path.

I also tried putting an "exe" file as a reference, but it just displays
all of the files in the directory instead of executing the file. (Kudos
to MS for not leaving a huge security hole here!)

Another interesting thing is that if you type a file url directly into
the address bar, environment variables are actually expanded!, i.e.:

file://%SystemRoot%/Index.htm

will look for "Index.htm" in C:\Windows\System". However, if the %..%
string is within an existing file (i.e. the http file), they will not be
expanded on the client system.

 

[Mike.Duffy]

Scripsit Mike.Duffy:

You don't actually see them much on web pages except as
products of wrong use of authoring software
...
Just stop the guesswork and upload the files onto a web server

My "application" is a js program that creates a customized short story
intended for a juvenile audience. The user is presenetd with a form where
the reader can enter names for the story characters. One feature of the
program that generates the story is that it puts little pictures next to
the text of the character who is speaking. (I.e. like most chat programs.)

I wanted to add a field to allow the end user (or his/her parent) to
specify the file name of a local gif/jpg/bmp file in order to customize the
pictures as well. (So the kid gets his own picture beside his name.)

I actually succeeded in doing this. Take a look at the reply to another
post in the same thread I made a few minutes ago.

You are likely correct about the app not working on systems I have not
tested, but if it works for Windows / IE6, that covers most people anyways.
If it doesn't work, the user can just leave those fields blank and use the
default pictures.

 

[David E. Ross]

I discovered by trial & error that it does work, (IE6SP1) and the default
is "C:\". The syntax is very specific. On the server, you can put the
full path, i.e. within url

http://index.htm

you can use

<a href="file://C:/Sub_dir/Index.htm">Click Here!</a>

as well, you can use just the file name, but not as expected.


This works:

<a href="file:/Index.htm">Click Here!</a>


but you cannot use:

<a href="file:Index.htm">Click Here!</a>

nor

<a href="file://Index.htm">Click Here!</a>

For unknow reasons, it takes a long time (~30 sec) to fail.


An interesting sidenote is that you can use:

<a href="file://server/share/Index.htm">Click Here!</a>

to access a shared resource.

<img ..> tags work perfectly as well. Note that there is a limit on the
length of the string. The above "full" path works, but not the complete
"My Documents" path.

I also tried putting an "exe" file as a reference, but it just displays
all of the files in the directory instead of executing the file. (Kudos
to MS for not leaving a huge security hole here!)

Another interesting thing is that if you type a file url directly into
the address bar, environment variables are actually expanded!, i.e.:

file://%SystemRoot%/Index.htm

will look for "Index.htm" in C:\Windows\System". However, if the %..%
string is within an existing file (i.e. the http file), they will not be
expanded on the client system.

You are citing IE6. On a Web page loaded from an external Web server, I
believe IE7 and newer Mozilla browsers will not load a file from a local
machine. It likely won't work also from Opera or Safari.

Accessing a local file from the Internet as if it were a Web page is
considered a security vulnerability. However, there are ways for a user
to upload a local file to a server. For an example, go to
<http://validator.w3.org/> and scroll down to "Validate by File Upload".

--
David E. Ross
<http://www.rossde.com/>

Natural foods can be harmful: Look at all the
people who die of natural causes.

 

[Jukka K. Korpela]

Scripsit Mike.Duffy:

My "application" is a js program that creates a customized short story
intended for a juvenile audience.

So your problem has nothing to do with authoring for the WWW, even though
you posted to c.i.w.a.h., too.

One
feature of the program that generates the story is that it puts
little pictures next to the text of the character who is speaking.

It sounds like you have no good reason to use HTML in the first place.
Surely there are better ways to create a user interface for an interactive
program.

 

[Mike.Duffy]

Scripsit Mike.Duffy:


So your problem has nothing to do with authoring for the WWW,

It is intended as a WWW-based application. I thought that was implicit by
virtue of the use of javascript and the "http://" url references.

Surely there are better ways to create a user interface for an
interactive program.

After the items are entered in the form and the button is pressed, it is
not really interactive anymore. The advantage of using the Web based
approach is that the end-user does not need to install a program to run it.

It sounds like you have no good reason to use HTML in the first place.

Bringing smiles to the faces of children around the world is a good enough
reason for me. What would you consider to be a good reason?

 

[Jukka K. Korpela]

Scripsit Mike.Duffy:

It is intended as a WWW-based application.

It was implicit in the lack of a URL demonstrating the idea that it was not.

After the items are entered in the form and the button is pressed, it
is not really interactive anymore.

If the form data is actually sent to a server, making this really something
that works on the WWW, then it's the file content that is submitted and you
don't need the original path name (and might not have any access to it).

 

[Mike Duffy]

Scripsit Mike.Duffy:


It was implicit in the lack of a URL demonstrating the idea that it
was not.

No doubt, a url to demonstrate would have made my query more clear.

But I prefer to make the whole site ready first. Someone else pointed out
that I should test it with IE7 and a few other browsers before publicizing
it. There is a lot of js, some of it much more complicated [*] than the
story generator I spoke about, so probably he is right.

If the form data is actually sent to a server, making this really
something that works on the WWW, then

My ISP limits me to static web pages. (No ASP/CGI).

For me, info need not go back to the server in order to consider it a WWW
"application", because in general, a program need not require external
input in order to be considered a true "program".

Thank you for your input. Also, your personal web pages gave me a lot to
think about. When mine are ready, I'll drop you an email to return the
favour.

[*] For reasons pointless to go into here, I needed to write javascript
that generates the actual javascript used to create the intended
functionality.