Yes. It goes against the intended use of URLs because it implies that the
returned directory will have filenames that are meaningful to the user.
But maybe that type of URL should be valid. I'd return titles, not the
directory list.
I have huge directories of files with filenames that are utterly
meaningless to the user (news items, hierarchical menus, people and company
profiles, etc.). I'd hate to allow users to waste server time grabbing
huge meaningless directories. I'm totally against any proposal that would
require filenames to be meaningful to the user, or even the client, for
that matter. They need to optimized for the server and whatever software
creates and maintains them.
I'm generating tons of files and filenames automatically. Twice I tried to
use meaningful file names (partly because AppleSearch, which I'm using,
returns filenames), but the complexities of automating that process are
nasty, especially when you're designing for the least common denominator
O/S -- DOS, with 8 chars and an extension, or even worse, CompuServe, with
six chars and an extension! Further, the HTTP spec rather clearly says
that URLs aren't meant to be interpreted by users.
Here's an alternative idea -- instead of returning a directory in response
to a URL like that, return a list of document <title>s as HREFs! Hmm, I
like that one... It would save the server from having to respond to a
series of HEAD instructions from a robot, among other things. Adding file
sizes might be nice, too.
My apologies to those who are also on Web4Lib who heard the same rants from
me yesterday... but at least I've come up with one good idea (I think)
since then.
Nick
Multimedia Computing Corp. (strategic consulting)
Campbell, California
----------------------------------------------------------
"We are surrounded by insurmountable opportunity." -- Pogo