Re: LINK TYPE=override/type

On Thu, 22 Jan 1998, Jukka Korpela wrote:

> On Wed, 21 Jan 1998, Neil St.Laurent wrote:
> 
> > A simple question about using
> > <LINK REL="Something" HREF="somwhere" TYPE="content/type">
> > Does the TYPE here override any returned type from the HTTP 
> > connection?
> 
[...]
> Perhaps this problem might be solved by a formal statement - an official
> interpretation - from the W3C.
> _My_ suggestion is:
> a) The TYPE value _may_ be used by a user agent to ignore resources
> with a MIME type which is not supported by the user agent. A user
> agent _may_ alternatively retrieve the actual resource and its
> announced MIME type and act according to it.

This is a good suggestion. 

> 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'd have to disagree with this suggestion. In the case of conflicting
TYPE value and MIME type (from HTTP) I think that the specified TYPE
value should have precedence. I think of TYPE as being used like 
type casting in some programming language, where it can be used to
over-ride or change the actual type of the resource. I can imagine that
there are many times when an authour would like to or have to over-ride
the server-specified type. 

As for reporting the discrepancy to the user, I also don't think it
would be a good idea. How helpful is this to the user, and what can
they do about it? Few users understand (nor should they have to
understand) what MIME types are. Choosing the wrong type could
have drastic consequences.

If the author of the HTML has bothered to put in a TYPE attribute,
I think they should be trusted to know what they were doing rather
than letting the user or browser second-guess them.


> c) User agents are _not_ required to check that the TYPE value (if
> present) and the MIME type with which the resource is served (if present)
> actually match. It is however strongly recommended that such checks
> are made and any mismatches are reported to the user. A user agent
> may inspect the resource itself to decide which of the MIME types
> is more plausible.
> 

c) seems to be slightly different wording of b)?


> One might say that b) is impractical, since mismatches typically
> result from servers not being configured properly, which is rather
> common. I suppose most servers nowadays would still send a .css file
> with Content-Type of text/plain or application/octet-stream, depending
> on which is the default for unrecognized file name extensions.

On my ISP, the .css extension was already being used for some kind of
specific application file type. Fortunately I was able to change the
MIME type for my own directories.



> In principle and in the long run, on the other hand, I would say that it
> is better to trust the information attached to a resource itself than
> information attached to a _reference_ to a resource. To take a simple
> example: Let's assume that someone puts plain text files onto the Web,
> later adds markup to them so that they become HTML files, without
> changing the file names (since there might be a large number of links
> around). Now, if someone has linked to them with <A TYPE="text/plain"
> HREF=...>, should the browser still display them as plain text although
> the server says Content-Type:text/html?

Well, if they were text/plain to begin with, I don't see why someone
would refer to them with that same type. I think the real usefulness
of TYPE is where there are conflicting or non-existent MIME types for
some resource.


Bill Bereza  bereza@pobox.com  http://www.pobox.com/~bereza/

Beware of all enterprises that require new clothes.

Received on Thursday, 22 January 1998 12:27:55 UTC