W3C home > Mailing lists > Public > www-talk@w3.org > March to April 1995

Re: distinguishing browser types

From: Robert S. Thau <rst@ai.mit.edu>
Date: Sat, 22 Apr 95 22:32:31 EDT
Message-Id: <9504230232.AA04993@volterra>
To: brian@organic.com
Cc: www-talk@www10.w3.org
   From: Brian Behlendorf <brian@organic.com>
   X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
   X-Comment: To sign off, send mail to listproc@mail.w3.org with body DEL WWW-TALK

   On Sat, 22 Apr 1995 wmperry@spry.com wrote:
   >   So netscape can't do inlined HTML then, eh?  If all it sends are:
   > Accept: image/gif
   > Accept: image/jpeg
   > Accept: image/xbm
   > Accept: */*
   >   Then a server should lump text/plain, application/postscript, text/rtf,
   >   application/x-ms-word, and text/html all with the same rating, and is
   >   free to send whichever it wants.  And application/x-ms-word would be the
   >   'best' one to most servers.

   Haha.  We ran into this as well with Apache - it seems some clients would 
   rather get "mother.gif" than "mother.html".  :)

   So, the server at least presumes "text/html; q=1" and "text/plain; q=1" if 
   neither are explicitely mentioned.  Of course, that may result in a bad 
   response to a VRML-only browser.....

Actually, that got deleted at Roy's insistence (the default specified
in the HTTP draft is *strictly* */*, if no explicit Accept: headers
are present, and that's what I went with).  If someone actually does
specify a type map (either explicitly or through a MultiViews request
for 'mother' where mother.gif and mother.html both exist), well, they
get what they get.

(Fortunately, enabling content negotiation won't ever break existing
links by serving up the wrong variant in cases like this, since
existing links always point directly to one of the variants --- always
to 'mother.gif' or 'mother.html', whichever is required, and never
just to 'mother', which gets bounced with a file not found unless
MultiViews is enabled and the server is allowed to cruise the
directory for possible variants).

This does indeed have the awkward consequences Brian outlined above,
but that's not *nearly* as awkward as what you get by defaulting 'q'
on */* to 1.0 if not specified otherwise (see previous message for a
description of those... glitches).  It has, at times, been a little
tempting to vary a bit from the strict letter of the standard for
cases like these (under control of some sort of config directive), but
I wanted to get the standard case right first.

Received on Saturday, 22 April 1995 22:32:38 UTC

This archive was generated by hypermail 2.4.0 : Monday, 20 January 2020 16:08:16 UTC