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 --- a few pointers still needed.
Date Mon, 20 Mar 1995 09:08:25 GMT
   Date: Mon, 20 Mar 1995 02:56:52 -0800
   From: "Roy T. Fielding" <fielding@avron.ics.uci.edu>
   Precedence: bulk
   Reply-To: new-httpd@hyperreal.com

   Good work Rob (rst)!

Might as well be rst.  There are too many Robs running around here...

   >    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.

   That is a good optimization, but there is a reason for it not being in the
   spec.  The parameters are part of the media type, so

	text/html              text/html;level=2    are the same (2 is default)
	text/html;level=2      text/html;level=3    are two different types

Hmmm... I had been assuming that any browser which claimed to accept
text/html (or, more generally, some media type foo/bar with multiple
levels) at level N would also necessarily accept it at lower levels
for back compatibility.  (This is hopefully the case for HTML!)  Bad
assumption?

   Also, the "level" parameter only applies to HTML and PostScript because
   those are the only types (that I'm aware of) which define that parameter.
   I suppose it is safe to make some global assumptions about level, but you 
   should be aware that this is not "normal".

I am.  The whole business is a little more ad hoc than I'd like, but I
guess it's what we're stuck with.

   > 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.

   No, this won't work -- it invalidates the metric (i.e. it changes the
   meaning of the result such that media types that *should* have been preferred
   get wiped out).

If that's the spec, that's the spec, but it strikes me as a little
counterintuitive.  (As a potential user, I'd want language to take
precedence over media type.  For instance, I generally prefer
postscript to plaintext, but I prefer English text/plain to German
postscript, since I can't get much out of the latter --- in other
words, I'd *want* the application/postscript media type "wiped out" by
language.  But the standard rules).

   > 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.

   Right -- someone pointed that out on the http-wg list and I agree with
   this interpretation.  However, there is no "q" -- the order is significant.

	Accept-Language: en-cockney, en

   is the equivalent.  Internally, you can think of this as
   "en-cockney;q=1, en;q=.99", but the number *must not* affect the media
   type equation.

Easy enough to implement; it'll just mean another spin through the
code.  (I need to bang on it a bit more anyway.  This really needs a
formal test driver, though; no typical Web client is going to generate
requests which are varied enough to test this code thoroughly, and
it's too easy to forget about some tricky case when you're typing them
in by hand).

   BTW, one thing you do need to be sure of is that each variant has its
   own URL which can be accessed independently of content negotiation --
   there needs to be some way for a user to say "this is exactly what I want"
   even when they have no control over what their client says it Accepts.

   .......Roy

Requiring each variant to be stored in a separate file, in a directory
which is mapped by the server anyway, *almost* covers this.  The
exception is when a map file names a content-type or encoding for
something which is *different* from what the server would conclude
from file suffixes.  This is a pretty fringe case; worth worrying
about? 

rst

Mime
View raw message