httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@ai.mit.edu (Robert S. Thau)
Subject Re: content negotiation filename extension
Date Mon, 20 Mar 1995 17:07:55 GMT
   Date: Mon, 20 Mar 1995 13:14:55 -0800 (PST)
   From: Simon Spero <ses@tipper.oit.unc.edu>

   I'm in a lot of pain at the moment, so this may end up short.

   For MDMA-3,4, in the basic file-system object store, the way I'm handling
   multi-typed objects that really exist, as opposed to having been
   dynamically generated, is through the directory-to-* converter stack.
   When an request is issued that should return a file, and the URL given
   names a directory, the variant list is from files in the directory of form
   'index.*' or '<directory-name>.*'.

I thought about doing something like this, but right now, there
already is a fairly elaborate list of things which NCSA httpd does
when a URL maps to a directory in the file-store, all of which have to
do with generating automatic directory listings; a lot of users have
come to depend on this behavior.

   Information about base types and 
   encodings comes from the extensions and the meta-base; I've been playing 
   around with adding a new meta-info handler that will also look at extra 
   extensions of the form attr=value.html.gz; I haven't had a chance to play 
   with apache much, but I'll take a look and see how easy it would be to 
   fit this in if anyones interested.

Note that the distributed apache versions don't include my current
content-negotiation code; if you want to beat on it, I could put up
the latest version fairly easily.

As to the suffix business --- look at find_ct in http_mime.c; that's
the function you have to hack.  (My content-negotiation code just
calls find_ct, via set_content_type, and uses whatever it put in
content_type and content_encoding to get metainformation on directory
entries).  My own feeling is that people who want to seriously mess
around with attributes will want them in a form they can edit, so map
files might ultimately be easier for them to use than filenames like
some_document.qs=0.8.level=2.ps.gz (note also that the '.' in 'qs=0.8'
poses nontrivial parsing problems).  But if anyone wants attributes in
the suffixes badly enough to code it up, I won't stand in the way.

(NB another way to handle this is an AddType directive which maps a
suffix to a media type *with attributes*, e.g., the

  AddType text/html;level=3 html3

which already appears in my Apache config files).

(Note also that there's something I've got on my queue to do with that
function *eventually*, which is language suffixes, e.g., getting the
content-language from filenames of the form some_document.en.html ---
however, I don't see any essential conflict between that and 'foo=bar'
suffixes for attributes).

   Simon

rst

Mime
View raw message