W3C home > Mailing lists > Public > www-html@w3.org > August 1999

Re: OBJECT's type attribute in 4.01

From: Nir Dagan <nir@nirdagan.com>
Date: Mon, 30 Aug 1999 12:14:49 -0400
Message-Id: <199908301613.MAA28914@dark.brown.edu>
To: Dmitry Beransky <dmitry@ostankino.ucsd.edu>, www-html@w3.org
The situation described below by Dmitry Beransky assumes that the HTML author 
and the HTTP server administrator work against each other.
The specifications (HTML and HTTP) assume, what is more reasonable, 
that they work in coordination. 

Thus, first a "content provider" (which is a single entity that does 
both authoring HTML and serving them in HTTP) should send identical 
MIME types in his type attribute, and in the content-type HTTP header.

Now, if the types attributed to the object are incosistent, the specs 
assumes that the *error* (not intentional inconsistency) is in the HTML 
page that referes to the object. This is very reasonable with the 
cooperation model of content providing.

It also should be pointed out that HTTP Content-Language header takes higher 
priority than a hreflang attribute in a link to the document. And the same
applies also to character encoding (the charset parameter/attribute) 

Nir Dagan 
At 08:34 PM 8/27/99 -0400, Dmitry Beransky wrote:
>Hi folks,
>The 4.01 spec refines the definition of OBJECT'S TYPE attribute as follows:
>    If the value of this attribute differs from the HTTP
>    Content-Type returned by the server when the object is
>    retrieved, the HTTP Content-Type takes precedence.
>Could someone explain the reason it was decided that http takes precedence 
>over the local type value?
>I would guess that between the author and the server, the author knows 
>better what the object's type should be.  The HTTP spec recommends that all 
>servers specify a Content-Type field and most server do.  Unfortunately, 
>they choose to revert to a default value (text/plain, binary/octet-stream, 
>etc) when they are not configured to support a particular media type.  This 
>happens particularly often with new media types.
>Imagine, for example, that I want to experiment with SVG files, but my ISP 
>doesn't know anything about SVG, or they know that it's still an 
>experimental standard, or for any other reason don't want to change the 
>server configuration.  In the mean time, the server continues to send my 
>SVG files as plain/text.  What am I to do, short of switching to a 
>different ISP?
>Having the TYPE attribute take precedence over the Content-Type field would 
>allow authors to deal with such situations, instead of relying on server 
>Any comments?
Nir Dagan
Assistant Professor of Economics
Brown University 
Providence, RI

Received on Monday, 30 August 1999 12:14:03 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:51 UTC