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: new code available...
Date Sun, 26 Mar 1995 18:41:57 GMT
   X-Uri: http://www.inetnebr.com/zyzzyva
   Date: Sun, 26 Mar 1995 16:21:39 -0600
   From: Randy Terbush <randy@zyzzyva.com>

   Oh.  I guess from previous discussion I assumed I needed to create
   a "map" file.

MultiViews and type map files are two alternative ways of getting
negotiation to happen.  MultiViews may be more convenient (just drop
the files in and it works); however, setting up a type map allows you
more control.

   How is it able to create encoding info etc..?? 

By intuiting from filename suffixes, as usual.  (It actually invokes
the same code used to set content_type and content_encoding on
non-negotiated requests).

   Interesting observation; when telling 1.1b1 to grab index.var, it
   read the index.html3 file.  Is this because I gave the index.html3
   a qs=1.0?

No, it's because you gave index.html a qs=0.5. ;-)

Seriously, here's what's going on here:  Of the four Accept: headers
that Netscape 1.1b1 sends, the only one matched by any HTML variant is

   Accept: */*

We might as well pretend that the others weren't there, since no
variants match them anyway.  As mandated by the current HTTP draft,
this is treated as

   Accept: */*; q=1.0

since no other quality value was explicitly specified.  There are two
available variants, specified as

   URI: index.html
   Content-type: text/html; level=2; qs=0.5

   URI: index.html3
   Content-type: text/html; level=3; qs=1.0

The server computes combined quality values for each variant by
multiptlying its qs by the value of q from the best matching Accept:
header (in this case, that's always 1.0).  If any variant exceeds all
the others in combined quality, that's the one we have to send, by the
requirements of the HTTP draft.  So in this case, index.html3 wins.

Incidentally, by my interpretation of the HTTP draft, it wouldn't have
mattered if the client actually sent "Accept: text/html", or even
"Accept: text/html; level=2", unless it added quality values to its
headers which gave HTML2 a high enough boost in quality over random
"*/*" stuff to overcome the factor of two difference in qs.

(Roy, hope I got that right ;-).

Note that if the variants had equal (combined) quality, then the HTTP
draft gives the server a little more leeway, and in those cases my
code will only send HTML3 when the client which has explicitly asked
for HTML3, or when no HTML2 variant is available.  So, MultiViews will
arbitrate these situations as you expect (since it assigns equal qs to
all variants).

I'm not entirely pleased with this outcome --- what you've done with
these two qs values seems intuitively reasonable; it's a bit
unfortunate that it makes the server hand HTML3 to clients who can't
handle it, and don't know enough to say so in detail (with appropriate
quality values on Accept: multiple headers).  However, I'm not sure
how to do better within the letter of the spec.

rst


Mime
View raw message