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

RE: OBJECT's type attribute in 4.01

From: Zoltan Hawryluk <zoltan@netcom.ca>
Date: Mon, 30 Aug 1999 10:32:58 -0400
Message-ID: <051686CF5E6CD211B8FC00A0C9D4CF450143865C@exmail.corp.netcom.ca>
To: "'Dmitry Beransky'" <dmitry@ostankino.ucsd.edu>, "'www-html@w3.org'" <www-html@w3.org>
Dmitry Beransky said:

> Could someone explain the reason it was decided that http 
> takes precedence 
> over the local type value?
>

my $0.02 :-)

let's suppose two companies, out of total coincidence, make a file format
that have, for example, .XYZ

let's assume they are both image formats and that the are not compatible for
each other.

there would be a problem embedding them in a web page because the browser,
being what it is, cannot distinguish between the two of them (*without* a
mime type).

this happens, for example, with .DOC files.   sometimes they are regular
ASCII text, sometimes they are MS-Word files.  the server is configured to
say which is which.

if you think about it, it is also a good secuity feature.  if a web
admin/sysadmin doesn't want people loading and executing, say, a shockwave
type file because s/he knows there may be an security hole in the plug-in
and doesn't want to be held responsible for what malicious users might
upload to the server, that admin could set all .SWF files to text/plain and
(theoretically) ensure that those types of files won't be recognised by the
browser correctly.  (i don't have anything against shockwave ... i just use
it as an example). 

again, just my $0.02, but i'd like to see what other people think about my
logic.

z.



 
> 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 
> administrators.
> 
> Any comments?
> 
> Regards
> 
> 
> 
Received on Monday, 30 August 1999 10:38:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 March 2012 18:15:39 GMT