Re: distinguishing browser types
Sun, 30 Apr 1995 07:42:07 +0500

Robert S. Thau writes:
> Date: Thu, 27 Apr 95 22:57 PDT
> From:
> But what about a browser that is ultra-configured, and really _CAN_
> display every type and its grandmother with no lossage whatsoever?
> Such a browser would have to figure out how to deal with media types
> which were just invented by the guy who runs the server, for which
> viewers are not generally available --- to say nothing of the fun to
> be had in writing the viewer for application/binary. Whoever figures
> out who to do all *that* can surely figure out how to get his browser
> to put an explicit "q=1.0" on the "Accept: */*" header, to suppress
> the inappropriate default ;-).

The browser writer isn't in charge of the helper apps. :) And I use
emacs as my viewer for application/binary. :)

> More to the point --- maybe I'm thick, but but I really don't see how
> a browser which deals "properly" with *any* media type could possibly
> exist, since people can invent new ones at will, so I don't feel
> obliged to cater to it (especially when every other browser out there
> would be served better by something else).
> Servers
> should make assumptions like this, no matter if they are justified at the
> moment. Browser authors should get off their !#%!#@ and do it right.
> Agreed --- if we can agree that "doing it right" means specifiying
> explicit quality values on Accept: headers.

Yup, that is my definition of 'right'. I just need to find a good gui
for it, instead of using the mailcap file.

> However, so long as the browsers *don't* provide quality values, the
> servers have to make assumptions, whether justified or not, and the
> only choice we have in the matter is trying to find the set of
> assumptions which will cause the least trouble. My personal view is
> that defaulting quality on everything, including */*, to the same
> value, isn't the right choice.

I don't think the default should be 0.5... the CERN daemon gives theirs
something like 0.000005 or thereabouts.

-Bill P.