It's clear that there is no default content type for HTTP/1.0 in practice.
[Not that it's much of an issue, but HTTP/0.9 always returns HTML or
plain text, and it signals plain text with <PLAINTEXT>. Perhaps that's
not how it works in practice, but that's how it originally worked. ]
As for the HTTP/1.0 protocol: I'd say:
An HTTP server must specify the content type of the response
data. There is no default.
NOTE: HTTP clients should be aware that some HTTP servers fail
to supply a content type, and they should do some reasonable
error handling (or guessing of the content type) in this case.
About the suggestion that the server return untyped data: that doesn't
play nicely with the format negociation algorithm. If a server can't
determine the type of some data, it shouldn't ship it to the client at
all. Note that it's reasonable to ship any data under the
"application/octet-stream" content-type, if the client Accept:s it.
What happens if the set of content-types Accept:ed by the client and
the set of content-types that a server can supply an object in don't
intersect? Is there an HTTP result code for "I don't have that object
in any format that you accept"?
I realize that every HTTP client must support text/html and text/plain,
but must every object be available as one of those? What about images?
Dan