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 :)
2) URL's, while powerful, can't completely express the exact request since
they don't specify what the other headers say, and those headers can
affect output, particularly for lines like Accept: or Content-Encoding:.
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.
I.e., some times I'll just want to link to a picture of my mother, not
caring whether it's the jpg or gif or tiff version, other times I'll
explicitly want to be able to link to the jpg version.
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.
On Mon, 6 Mar 1995, Rob Hartill wrote:
> > However, I see that if you had a directory containing .gif and .jpeg versions
> > of many images, it would be tedious to have to create a .shtml map file for
> > every image. So how about a default wildcard mapping set in the .htaccess
> > file in the directory? That way, the server would read a per-directory list
> > of extensions to stat for, rather than having to try everying the browser
> > accepts.
>
> The script and hack I've got for 1.3 does something very similar to
> this. A global MIME type can be set so that any file ending with
> a particular extension can be checked for negotiation, e.g.
> one could set an extension .img which when requested would be
> intercepted by httpd and passed to my cgi-script, the script then
> looks for a conversion table by that name, if it doesn't find one
> it looks for a table in that directory, then in the document root.
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 :) 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?
> See http://ooo.lanl.gov/explain.html for some old info.
Looks like you've already implemented this :):) Now to move chooser.pl
into the server and do away with the need to look at user_agent or
redirects...
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@hotwired.com brian@hyperreal.com
http://www.hotwired.com/Staff/brian/