Re: LINK TYPE=override/type

Jukka Korpela felt an urge to reveal at 7:49 AM -0000 on 1/22/98:
> b) In the case of detected mismatch between the TYPE value and
> the MIME type with which the resource is actually served (determined
> e.g. from HTTP headers), the latter is to be obeyed. A user agent
> may, however, report the situation to the user and allow him to select
> between the alternatives.

I disagree completely. What's so sacred about the type that a server gives?
So often a server delivers many different types of files as random mime
types (the most popular being ocet-stream something). The idea is that it
is more important what the browser itself can do with that resource. After
all, on a really poorly set up server, it's possible that
HTML,VRML,CSS--indeed, any file in a text format, *could* be sent as
text/plain, which would be a bad thing. If the browser is told what type it
is, it will know how to deal with it, no matter what the server calls it.

This is also true with the (yes, I know it's not W3C standard) EMBED
element, in which one possible attribute is TYPE. Now, I've vistited many a
page where I'm told that I don't have a plugin that supports "text/html" or
"ocet-stream" (or whatever the latter is actually called), when in fact
what the web page author is trying to place is a movie file, sound file,
midi file, etc.

I think that in this case the browser can rely on the somewhat more
purposeful intentions of the web author rather than the mechanations of a
server.

-------------------------------------------------------
[           Jordan Reiter                             ]
[           mailto:jreiter@mail.slc.edu               ]
[  "It's well known that dead people are all sick     ]
[   because they're too depressing."                  ]
[   -- from http://www.icemcfd.com/cgi-bin/make_flame ]
-------------------------------------------------------

Received on Thursday, 22 January 1998 11:29:22 UTC