Content Negotiation --- a few pointers still needed.

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

There were a few things I couldn't quite figure out from the current
HTTP draft regarding content negotiation; I also extended it a bit in
one or two ways.  Here's where I may be confused (among other things,
why I'm not sending 406 yet):

1) The spec. says nothing about "level=foo".  My code treats an
   unspecified level as zero (except for HTML, where it's two --- this
   is acknowledged as a kludge by everyone --- ideas?), and refuses to
   serve a client a variant at a higher level than it has stated it
   can accept (as if it exceed maxbytes).  (Files in the filesystem
   will also typically wind up at level zero in those cases, so it all
   works out).

   If multiple variants are acceptable and have the same quality
   rating, the one with the highest level is chosen --- this gives
   clients which say "Accept: text/html; level=3" without giving it a
   quality value which would distinguish it from plain HTML will still
   get the HTML3 variant.

2) Two kinds of MIME type wildcarding show up in the spec: */* and
   foo/*.  However, I'm not sure if something more general is meant.
   These two forms will work as intended in my code, but anything else
   is likely to have unintended consequences.

   Also, if multiple Accept: headers match a given variant's MIME
   type, this code chooses the one which gives it the highest quality
   rating (rather than, say, the most specific).  Since more specific
   types will generally have higher quality ratings anyway (will
   anyone ever say "I want any application/* except postscript?"),
   this probably doesn't make much of a difference.

3) I couldn't get even Arena to understand returned Content-types with
   parameters.  For the moment, I'm stripping them off.  (When I tried
   telling Arena that something was "text/html; level=3.0", it
   displayed it as plain text).

4) My code allows quality values are on Accept-Language: and
   Accept-Encoding:.  This is an extension to the letter of the spec,
   but it's also supported, I *think*, by CERN httpd.  Quality factors
   on the Content-language of a particular interest are multiplied
   into the quality factor which is produced by the MIME type;
   likewise for encodings.

5) The spec isn't entirely clear on how language tokens are compared.
   This code does it as follows: The tokens in clients'
   Accept-Language headers are matched against the *same-length
   initial substrings* of the content-languages of the variants.
   Thus, "Accept-Language: en" matches both "Content-Language: en" and
   "Content-Language: en-cockney"; also

     Accept-Language: en-cockney; q = 0.8
     Accept-Language: en; q = 0.5

   will work as intended.  

6) I'm not sure what a 406 None Acceptable response should look like.
   The current draft specifies that no entity-body is allowed in such
   a response, and that the Content-type and Content-encoding should
   be those of the entity.  I see two potential problems here.

   First off, if the entity has multiple variants, it isn't clear how
   the server is supposed to say what they all are, and which encoding
   goes with which type.  (For instance, if the two available variants
   are gzipped postscript and uncompressed richtext, I'm not sure
   what the response should look like).

   Second, and more seriously, current browsers will attempt to treat
   such a response as a zero-length entity of whatever type, generally
   resulting in a blank display or a dialog box offering to save a
   zero-length file, rather than showing their users a description of
   what went wrong.

   (FWIW, these would both be easier to deal with if the spec
   specified that a 406 should have a body which gave URCs for the
   available variants, in some suitable format).

   For the moment, I'm continuing to return 404 for these cases; also
   the wrong thing, to be sure.  Fortunately, this isn't likely to
   come up much, as almost everyone sends either "Accept: */*"
   headers, or no Accept: headers at all (in which case we fake up an
   "Accept: */*").

rst