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.