Re: default return is "text/html"?
Thu, 14 Jul 1994 11:06:44 +0200

> Two comments to the current discussion:
> 1) Take a look at the specs at
> They say the following about Content-Type:
> "As defined in MIME..."
> Now take a look at the MIME spec, rfc1521: about unknown
> content-types:
> When a mail reader encounters mail with an unknown Content-type
> value, it should generally treat it as equivalent to
> "application/octet-stream", as described later in this document.
> So my conclusion is that the specs _do_ say how to handle the situation!

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 <>