Re: distinguishing browser types

   Date: Sat, 22 Apr 1995 13:44:48 +0500
   Reply-To: wmperry@spry.com

     Emacs-w3, AIR Mosaic, OmniWeb, and a few others (haven't checked out
     EMosaic for a while, sorry).

     The main problem is not that they set the accept headers wrong (I don't
     think netscape does - are you sure its broken?),

I honestly haven't checked 1.0, but the 1.1 betas send the same set
of Accept: headers on any request --- three image/* types and */*.
Not only doesn't this tell you what helper applications are available,
it also gives you no way of knowing whether the browser itself handles
tables or not (a nontrivial issue for those of us who'd like to avoid
a repeat of the forms chaos).

(Arena sends "Accept: text/html; level=3", among other things ---
Apache 0.6.2 uses that to identify tables capability in a client.  You
can see that by looking at http://www.ai.mit.edu; the <pre>-faked
table at the top turns into a real one if you look at it through
Arena). 

     but that they do not
     specify the maxsize, maxtime or quality attributes on the frigging
     things.  Which can completely hose things when you then send a */* at the
     end, which netscape and mosaic/X both do.

Actually, there is a way for a server to fudge this, at least in
simple cases.  The current HTTP draft says that when all available
variants have the same quality (actually q*qs, where qs is the
server's own quality rating for the variant in question), the server
can choose to send any available variant, choosing however it likes.

Apache 0.6.2 uses this freedom to prefer media types which the client
actually named to the ones which just matched a wildcard.  This only
does what you want if all the variants came out with the same
"combined quality" (q*qs), but if they all had the same qs going in,
and the client didn't set quality ratings of its own, that is what you
get.  (I'm to blame for this trick, I guess, having written the Apache
content negotiation code).

However, all is not well, even with this somewhat awkward hack --- if
the client specified no quality values on its Accept: headers (meaning
they all default to 1), and the server knows 'qs' values for the
variants, then the letter of the current HTTP draft requires the
server to always send the variant with the highest 'qs', even if its
media type only matches the */*, and not any of the others.  This
turns setting 'qs' values (which Apache allows, through the *.var
type-map machinery) into a real misfeature.

Things would work a whole lot more sensibly if the quality value on
wildcard Accept: headers defaulted to something low --- say, 0.1.
(This 0.1 would get multiplied into the 'qs' for variants with media
types the client didn't specifically name, which would direct the 
server to choose something else).

Unfortunately, I understand that lowball defaults for 'q' on wildcard
Accept: headers got shot down at the most recent IETF.  Sigh...

rst

Received on Saturday, 22 April 1995 14:22:34 UTC