Re: distinguishing browser types

wmperry@spry.com
Sat, 22 Apr 1995 18:25:04 +0500


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.