Re: Content Negotiation, imagemaps and type maps

["Robert S. Thau" <rs...@ai.mit.edu>]

   Date: Mon, 6 Mar 1995 16:04:15 -0800 (PST)
   From: Brian Behlendorf <br...@wired.com>

   I considered another two cases where automatic content negotiation causes 
   problems (so I disband my case for it):

   1) Someone who created a page "mother.html" which inlined the image
   "mother.gif".  Most browsers send "Accept: image/gif" in their headers even
   to HTML requests, so clearly we can't have the server assume that mother.gif
   is just the gif version of the mother.html page :) 

This is a real problem --- you could control it by making negotiation
be a per-directory option, and leaving it off for legacy cases like
this, but having to go around turning it off (or making sure to only
turn it on in new directories) could be a real pain.

   Thus, we need to have a way for content providers to be able to 
   explicitely link to a content-negotiating version of a resource 
   separately from the link where a particular content-type is desired.  

Ummm... for the record, the CERN scheme for automatic content
negotiation allows this --- http://.../foo does content negotiation
among foo.ps, foo.dvi, foo.tex, and foo.html, while http://.../foo.tex
retrieves the .tex version and ignores whatever others might be
present.  That doesn't overcome objection 1, however.

   So, like it or not it looks like content negotiation has to be
   specified on a per-document level using 3rd-party files (like
   gopher menu files) until we have meta-informational file systems.

I still don't like the potential for administrative hassles, but
you're right --- we get those either way.  At least this would give us
a place to put spare headers (stick them in the meta-files along with
the type maps).

On another subject:

   Can your system be used for imagemap files as well?  For example,
   NetSite allows you to use http://host/path/mapfile.map instead of
   http://host/cgi-bin/imagemap/path/mapfile.map - as the server does
   the imagemap processing internally (again a good hack ripe to be
   implemented into 1.3 :)

I've been doing this for ages, without any server hacks at all; I just
modified the NCSA imagemap script so that it takes the location of the
map file as its first argument.  I then prefix the map files with what
amounts to:

 #! /.../cgi-bin/imagemap

These mutant map files are installed as CGI scripts (you have to be
able to have CGI scripts in file directories for this to work; that
used to be an AI-only feature but not anymore).  When the server
exec's them, the Unix kernel sees the #! line, and runs the imagemap
CGI script with the address of the mutant map file as the first
argument.  Then imagemap opens that file, reads out the map data, and
we're off.

(I think something like this could be used to get the effect of Rob
Hartill's type-map hack as well, though there might be a little
trouble with the per-directory maps.  However, you'd have to either
recode the underlying Perl script in C, or write a trivial C program
which exec's perl with the right arguments --- "#! foo" where foo is
itself a program which tries "#! perl" doesn't work very well).

   That's the way I'd like to do this: let's say I have /path/mother.gif
   and /path/mother.jpg.  To explicitely allow content negotiation for this
   resource I link to a file /path/mother.img - that mother.img would work like
   a mapfile in that it describes certain criteria that match certain other
   files. I don't know what the format of that file would be like... 
   Also, this would be greatly enhanced if instead of issuing a Redirect the
   server could respond "here's the jpg file, but you (the client) should 
   be aware the URL this is really known as is http://host/path/mother.jpg".
   I didn't see any codes that matched that - Roy?

Hey, if you're passing out redirects anyway, you can just make the
*.img file a script which returns Location: and it works right now;
just stick an "AddType .img application/x-httpd-cgi" into access.conf.
(Actually, if the Location: is a relative URL, the server tries to
fetch it directly, and doesn't even send the Redirect, so you've got
that too).

I'd still prefer to see this in the server itself in the long run, for
two reasons:

1) Efficiency.  Compared to just about anything else, forking and
   execing CGI scripts is ssslloooowwww.

2) Security.  There are plenty of people who might want to enable
   content-type arbitration (or imagemaps) in directories where they
   *don't* want scripts; the server should allow this.

rst