Re: default return is "text/html"?

Daniel W. Connolly (connolly@hal.com)
Tue, 19 Jul 1994 15:48:48 +0200

In message <9407190708.AA09758@tipper.oit.unc.edu>, Simon E Spero writes:
>To try and get some sort of closure on this issue:
>
>
>How's about: All HTTP/1.0 Responses whose non-header portion is non-empty must
>
>include a Content-Type field. HTTP/0.9 reponses should be considered untyped,
>and
>type inference is the responsibility of the client.

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