Re: review of content type rules by IETF/HTTP community

HTTP has a defined media type in Content-Type because it indicates
how a given body is supposed to be processed, not just the particular
arrangement of bytes.  A great deal of functionality that uses the Web
depends on that indication of processing behavior, much more so than
the general-purpose browsers that ignore every error for the sake of
dull simplicity.  HTTP will not be changed just because the default
configuration of the software distributed by four vendors is based on
a theory that all users are too dumb to handle errors -- there are
other applications that use the Web that do not suffer from such
bad design.

There has been a great deal of speculation about how hard it is
to associate new media types with extensions.  That is a myth.
It has been over ten years since I last encountered an ISP that did
not give every single author at least two (and usually four) different
ways to assign the media type on any given URL, in addition to the
default config based on filename extensions.  The only reason that
resources don't get assigned correctly is because testing does not
reveal the error.

MSIE added sniffing, which broke down the relationship between
authoring and testing new resources.  Sniffing itself is understandable
as a work-around, and it makes sense to have a single default way of
doing that sniffing in a separate draft on browser standards
(not HTML or HTTP), but it is foolish to think that browsers can
sniff the intent of a content provider.  There are many resources
for which "text/plain" was specifically chosen to provide a source
view of some other text-based script or mark-up language -- no
amount of automated statistics gathering can say otherwise, since
there is no way to differentiate such resources by sniffing.

Sniffing loses functionality -- it causes known good content to
appear as errors on such browsers.  The fact that some people don't
care to support some parts of the Web's functionality should
tell you that this is an issue of client-side preferences,
not protocol, and must be defined that way by any specification.

....Roy

Received on Tuesday, 21 August 2007 17:10:06 UTC