Bug in <BASE ..> or in relative URL's? RFC for CGI-specification

Frank Majewski (fmajewsk@awi-bremerhaven.de)
Thu, 25 Aug 1994 14:41:42 +0200

Hi (developers),

I've written a CGI-script which responds to a request showing the client
where to find files at it's local side, (because you need a server for
executing local scripts...).

Suppose you invoke a client with a local file in your current working
directory eg. (/home/my/current/dir $ Mosaic form.html &)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
snapshot of my shell

The <HEAD>-information (in script's output) should be like
<BASE HREF="file://localhost/./">
which SHOULD work as expected: ie. saying "The prefix of all following
relative URL's is at your local side in your current
directory (independantly from where you are), so all following (relative)
URL's correspond to subdirs of your current dir!"

But when the client gets the answer of its request the current directory
HAS TO BE EXPANDED (in the <HEAD>-statement) to something like
<BASE HREF="file://localhost/here/must/be/your/ABSOLUTE/path/">
or regarding to the above:
<BASE HREF="file://localhost/home/my/current/dir/">
to work as it should be: The client can find the file
<IMG SRC="PicDir/Picturegif">
physically under (/home/my/current/dir/PicDir/Picture.gif), but of course
the short "./PicDir.gif" could be enough information to find it.

The problem (BUG?) is that the server can't know the absolute (prefix) path
at client's side and time of sending, because this can be mounted at
different places, on different drives or file systems.

I think that should be no problem because the CGI-script is only able to
answer very special requests and ASSUMES that THERE EXISTS a subdir at client's
side which matches the posted RELATIVE URL.

There seems to be no CGI-environment-variable (wrong terminology, I know!?)
like
CLIENTS_CURRENT_WORKING_DIR = /home/my/current/dir/PicDir/
which could be evaluated at server side so my only possible solution
(emulation!) is to create an extra input field in the form, in which the
user has to specify it's current working directory ABSOLUTELY (VERY
UGLY and maybe unknown: Does EVERYBODY really know it's (maybe transparent)
"mount-point" when always using synonyms like "~fmajewsk/....."?)

Why is it not possible to check for "file://localhost/./" and supposing
NOT to start at root (with the absolute path) but at your current dir? (This
is only relevant using "file://"-(pseudo)protocol so this is not a
security question: if you use "http://" all is done by the
server, isn't it?)

Is it dangerous when a server knows where a client actually "is"?

Any comments?

Frank