Re: default return is "text/html"?

Michael A. Dolan (miked@CERF.NET)
Tue, 19 Jul 1994 07:55:50 +0200

Currently, there is type guessing going on in both the httpd and (CERN-
library-based) browsers to result in a (hopefully accurate) Content-Type.
However, when the Content-Type is not specified in the HTTP reply header,
why does there have to be default ?

Why can't "I don't know" be a valid reply ?

If you define a default, then any compliant httpd would always stuff in
that default. Thus, the uncertainty about the document content is lost.
Similarly, if a client blindly assumes a default without trying to
figure it out, there is a similar loss of information. In other words,
it is valuable to know that the content is uncertain.

Proposal: There is no default HTTP Content-Type.

If Content-Type is missing in the HTTP reply header, then the client should
assume that it was unknown to the server and should try to figure it out on
its own based on the path, and/or file content and/or context of the retrieval.

Blindly assuming anything ("text/plain" or "text/html") is worse than knowing
it is unknown.

The only ambiguity here is whether the server didn't know the Content-Type
or whether the server is broken and simply forgot to add the field.

We could add a new MIME type, "application/unknown" as the default and require
compliant httpd's to provide this and/or clients to assume it. However,
provides no more information than if the Content-Type field is missing.

Michael A. Dolan - <>
TerraByte Technology (619) 445-9070, FAX -8864