> > Well, I think the base of MS-Windows IS MSDOS and the MSDOS-file system
> > recognizes the '.' as your actual (current working) directory. So sorry,
> > but I don't understand what the problem is.
>
> The problem is that there is no one current working directory. There's a
> current working directory for A:, one for B:, one for C:, and so on.
Ok.
> Also, these "current directories" change as the user manipulates other
> programs. There isn't one "current directory" per process. There's just
> one per disk.
Well, I think this is not right in general, see later...
>
> > > So... which current directory should file://localhost/./ reference there?
> > Just where you started, see above.
>
> Ah. Then you mean that file://localhost/./ should refer to the directory
> that the HTML client (Mosaic in your example) came from.
Yes, sorry if that wasn't clear...
> Let's say my current directories are A:\one and C:\two and Mosaic is in
> C:\bin and C:\bin is in my path. My current drive is A: when I invoke
^ Doesn't matter where your Mosaic is.
> Mosaic with file://localhost/./ What should it look for?
No, no, no. I DON'T invoke Mosaic with "file://localhost/./"!
I will try it again using your example:
Let's say you invoke Mosaic with a local file named form.htm (supposing
using DOS and saying 'A:\ONE>Mosaic form.html'). Your document URL at the
top of Mosaic now (should) say
"file:://localhost/A:\one\form.htm", ok?
In form.htm is a FORM with "ACTION=http://the.server.url/cgi-bin/dotheform".
This little program assumes that there exists a subdir under your local dir
from which you started your browser, ie. A:\one\Picdir\Picture.gif.
The server says (via the output of 'dotheform' for eg.
<IMG SRC="PicDir/Picture.gif">
), AND THE MOST IMPORTANT: in the HEAD-information is an entry like
<HEAD><BASE HREF="file://localhost/./"></HEAD>
because if you don't say something like that Mosaic trys to look for
the answer <IMG SRC="PicDir/Picture.gif"> at SERVER's side:
<IMG SRC="http://the.server.url/cgi-bin/PicDir/Picture.gif"> and this
will never find this file...
So what I want is the following:
1. the browser remembers the full prefix of loading a local file:
file://localhost/A:\one\form.htm (automatically completed at invokation
time)
2. The browser gets the <BASE>-information and if the returned BASE is
"file://localhost/./" (for example! Any other suggestions are welcome!)
the server tries to say that
the client now has to search at it's local side (in invokation dir),
the returned RELATIVE URL belongs to the previous invokation
directory, ie. composing
"file://localhost/./A:\one\PicDir\Picture.gif"
will be the right URL.
This seems to be a normal behaviour to me because if you browse local files,
you CAN USE RELATIVE URL's like <IMG SRC="PicDir/Pic1.gif"> or
<A HREF="Text/HTML/Another/File.HTM"></A> or something like that, even if
another process changes the current dir (think about side-effects if it
would be if so!).
The browser has to complete the
abbreviation of <IMG SRC="PicDir/...."> to (internally) full:
<IMG SRC="file://localhost/A:\one\PicDir\...."> (independantly from the
change of other processes [referring to some more or less multitasking OS]
and this will be the right BASE for ALL following RELATIVE URL's, do you
understand?
The only (nerving) problem is that a server NOW has to reply the FULL URL in
the <HEAD>-info (ie <BASE HREF="file://localhost/A:\one\">) as a 'prefix'
^^^^^^^
This is something the server
can't know! Otherwise you have a non-consistent URL scheme:
<IMG SRC="http://the.server.url/cgi-bin/PicDir/Picture.gif">
BTW: What about a special environment variable CLIENTS_CURRENT_DIR (or
something like that)? This would easily solve this problem and that's
why I ask the talklist (referring to CGI-spec's)
> That is the problem I'm referring to.
>
> > > Remember, HTTP is not just UNIX. -- Darren
> > ^ Of course, but I wrote too that this all is only related to
> > "file://"-(pseudo)-protocol, which has nothing to do with HTTP.
>
> Well, HTTP runs on more than UNIX, as does Mosaic and other HTML-based
> clients, is what I meant. file://... does indeed have something to do
Of course!
> with HTTP, since you want your server returning that over HTTP to a
> client, yes? Wasn't that your whole point?
You have to distinguish strictly what happens. Sure, the only way talking
between client and server is using HTTP. But at this time there is no way
to say (at server side) via HTTP: "Keep on looking at your side after
now!" (to the client) (which will not take care of HTTP in this case;
otherwise you couldn't browse on any non-connected computer anyway!
See the source of treating "file://"...it's just an normal "open")
>
> Let's take this offline if we continue. It's getting kind of silly, and I
> think the point is made.
This was the last public posting. Any further will be sent directly.
Any comments?
Frank (sorry if my English is difficult to understand...)
