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-type negotiation: thoughts and code
Date Thu, 16 Mar 1995 15:08:33 GMT
   Date: Thu, 16 Mar 95 16:31 GMT
   From: drtr@ast.cam.ac.uk (David Robinson)

   Can the mapfile begin with an identification string please?
   In the future we might want the content type of a file to be determied
   by the first few bytes of the file.

We could, sure... any suggestions?

   In any event, I would imagine wanting a *.doit feature for map files;
   it would be nice if we didn't have to invent a new extension for it.

Well, the '*.doit' effect (looking for filenames with added suffixes
if a file with the specified base name isn't present) is already
used by MultiViews.  I suppose we could say that if MultiViews finds a
map file, it could use it, but that relies on extensions again, and
it's a bit of a kludge.  (NB the extensions are configurable; what it
really relies on is a magic MIME type).

(No, losing MultiViews is not an option).

   I would suggest this syntax for a content negiotation map file:
   <!--#select
      language="en"
      type="image/gif; qs=1."
      file="pic.gif"
   -->

   That way, it would be easier to integrate this feature into .shtml parsing.

If you're suggesting that we should have content-type negotiation be
sensitive to some of the contents of the file, I'm sympathetic, but
the *right* way to do that is to handle <META>, not to build on
.shtml.  There already is a spec for this, and I'm a little hesitant
to reinvent the wheel without due cause.  (In any case, parsing isn't
the hard part).

If you're suggesting that map files, i.e. files whose sole purpose is
to direct the content-negotiation process, and not to be shipped to
clients, should look like .shtml, I'm not sure I see why that's a good
idea.  (It doesn't make things any easier to write, BTW; the includes
code is committed to writing whatever it finds down a FILE*, which is
very much the wrong thing when you're still trying to figure out what
to retrieve.  Besides, for a variety of reasons, I'm trying to
minimize the impact of my current content-negotiation work on the rest
of the server).

   Note that it should also be possible for the selected object to be a directory,
   although you'd have to cope with multiple map files in a single path.
   (e.g. as in http://host/path/language-map/countries/image-map/canada)

    David.

I'm not sure I understand what you're requesting here.  Is the
suggestion that "language-map" would map directories like

  en
  kr
  fr

and then "image-map" would direct MIME type discrimination?  If so,
it's a neat idea, but *very* hairy to implement, in the context of the
NCSA base code.  I'd prefer to get one-level discrimination working
solidly first, before having a go at this.  That's messy enough!

rst

Mime
View raw message