Re: distinguishing browser types

Alexei Kosut writes:
> On Sat, 22 Apr 1995, Kee Hinckley wrote:
> 
> > Which leads me to another question. Are there any browsers out there that
> > actually set the Accept fields based on the helper applications?  I know
> > Netscape doesn't. It makes it rather difficult to determine what formats
> > can be sent to a browser.
[...]
> This makes sense, really. If you're going to provide an image for an IMG 
> tag, you might like to know what image formats the browser can take for 
> this position. If the browser gives an "Accept: image/jpeg" because it 
> has a helper app that can view it, that can screw up what you're trying 
> to do, because you might assume that this means it can handle it in-line 
> as well.

  If a browser does this, it is _WRONG_.  For an inlined image request, a
  client should only send the types it can handle inline.  Emacs-w3 does
  this for its images and mpegs, and AIR Mosaic does this for images as
  well.

  And you should really only ever send */* if you know you are dumping to
  disk.

> Obviously there's a conflict here, but it seems that browser authors (at 
> least, the current versions of Netscape and NCSA Mosaic both seem to) 
> have decided for the in-line only option. This seems to make sense, not 
> to mention the fact that it saves net bandwidth for the request headers - 
> only four or five instead of seven zillion.

  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.

  I'd consider that a bad thing as a server guy. :)  And I'm sure the
  client user wouldn't like it either.

-Bill P.

Received on Saturday, 22 April 1995 18:22:40 UTC