Actually, the question here is not what to do if the Content-type is
*unknown* -- we're discussing what to do if it is *missing*. This is
also covered by MIME:
Default RFC 822 messages are typed by this protocol as plain
text in the US-ASCII character set, which can be explicitly
specified as "Content-type: text/plain; charset=us-ascii".
If no Content-Type is specified, either by error or by an
older user agent, this default is assumed.
> 2) In my opinion a missing content-type is equivalent to an unknown
> content-type. I think it is a very narrow solution to assume that
> everything unknown is HTML (or plain text) - this does not comply
> with the normal level of abstraction in HTTP. The right thing
> for the client to do is to treat it as "application/octet-stream"
> and then dump the whole thing to a local file for further processing.
I disagree -- a missing content-type is probably caused by a careless
server (or CGI script), while an unknown one probably means that your
client software (or its .mailcap file) has to be upgraded. Note that
if the content-type is specified as foo/bar, where foo is a known type
but bar is an unknown subtype of foo, the client should not default to
application/octet-stream but to something dependent on foo -- e.g. for
text/bar, text/plain should be assumed.
--Guido van Rossum, CWI, Amsterdam <Guido.van.Rossum@cwi.nl>
<URL:http://www.cwi.nl/cwi/people/Guido.van.Rossum.html>