filetype extensions

Rob Earhart <earhart+@CMU.EDU>
Errors-To: listmaster@www0.cern.ch
Date: Mon, 9 May 1994 22:25:10 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <8hndfDG00WC7A0yyN=@andrew.cmu.edu>
Errors-To: listmaster@www0.cern.ch
Reply-To: earhart+@CMU.EDU
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: Rob Earhart <earhart+@CMU.EDU>
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: filetype extensions
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Organization: cmu
Organization: cmu

  Okay, I've run into a small dilemna.

  I wrote a www server from scratch at the same time that I began
supporting Mosaic as a contributed application at Andrew, for the
experience of writing the server, gaining a full knowledge of the
protocol, and because I was bored :-)

  Embracing the http/1.0 concept of multiple content types for the same
document, the server takes the Accept: list from the client, turns it
into a list of extensions, and attempts to access each path.extension in
turn.

  So a user can have "foo.gif", "foo.xpm", "foo.jpeg", and "foo.ppm" in
their www directory, and access it as "foo" from the server, leaving it
to the client to insert things like "Accept: image/gif", and the server
to hand back something that the client can deal with.

  The problem:  I've run into substantial resistance to the idea from
the user community.  They want to add hyperlinks to "foo.gif", not
"foo".

  I'm getting two arguments for the use of extensions in the URL's:
People want to be able to use 'file:' and relative links to view their
files without going through the server (and maybe get the server to
translate pages on the fly when requested from AFS sites into 'file:'
links, reducing HTTP server load), and they want to maintain
compatibility with the other AFS www server on campus (run by our School
of Computer Science), which handles extensions the "normal" way.

  I've also had a request to try to resolve document types only when the
client doesn't send an extension on the request; the problems here are
that the extension in the URL is still significant (which seems a bit
backwords), and that eventually I'd like to implement a mechanism to
allow the user to use the extensionless file to specify versions of
documents in different languages, character sets, and encodings.

  So... what do people think?  Pragmatism or Purism?  Should I bow down
to the pressure to stop having it try to add extensions?

  A better question: does anyone have a *good* http namespace <-> unix
filesystem namespace mapping?  Taking into account varying content
types, encodings, languages, and the various "preferred" modifiers that
can be attached to all of these?  :-)

  )Rob