Re: URL ambiguity

eostrom@gac.edu (Erik Ostrom)
From: eostrom@gac.edu (Erik Ostrom)
Message-id: <9309172228.AA04420@gac.edu>
Subject: Re: URL ambiguity
To: kevin@scic.intel.com (Kevin Altis)
Date: Fri, 17 Sep 1993 17:28:30 (CDT)
Cc: www-talk@nxoc01.cern.ch
In-reply-to: <9309172146.AA33464@rs042.scic.intel.com> from "Kevin Altis" at Sep 17, 93 02:43:13 pm
X-Mailer: ELM [version 2.4 PL17]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1927      
Status: RO

> Should servers always require an explicit URL and not allow default
> behavior such as displaying the file "index.html"? 

Certainly not.  An HTTP path is not a file system path.  The server
should be free to do any interpretation it wants, provided that it
maintains the general URL constraints--mainly that "/" indicates
hierarchical structure in the ways outlined.  So this is not a
"default behavior", it is the way the server chooses to interpret the
empty file name.

>						     Should the URL syntax
> require a "/" at the end of a directory name?

I think the answer here is that HTTP has no notion of "transmitting a
directory".  So, yes, a directory name ends with a "/", but it's
always followed by a file name--even if the file name is the null
string.  In your example:

>         http://www.uth.tmc.edu/newton_info/

refers to a "file" with a very short name ("") in the "directory"
newton_info.  (File and directory are in quotation marks because,
again, they don't have to refer to filesystem elements--for example,
"newton_info" could be just the name of a gateway, for all I know.)
And

>         http://www.uth.tmc.edu/newton_info

refers to the file "newton_info" in the top-level directory.

(The server _could_ respond to the latter request with an
automatically generated menu, in which each of the links has an HREF
like "newton_info/foo"...  Of course, that becomes annoying if you're
trying to maintain an index.html page--automatic conversion of the
links there would be possible, but is not trivial.)

What this means is that you shouldn't be passing around a URL that
points to a directory and doesn't end with a slash (have an empty file
name).  IMO, if a server _gets_ such a URL, it should either convert
the links to point into the directory ("newton_info/foo") or refuse to
serve the URL; it shouldn't just return what it would return for
"newton_info/", as that will most likely be wrong.