Re: default return is "text/html"?
Garrett Arch Blythe (doslynx@falcon.cc.ukans.edu)
Tue, 19 Jul 1994 20:04:33 +0200
On Tue, 19 Jul 1994, Daniel W. Connolly wrote:
> ...
> It's clear that there is no default content type for HTTP/1.0 in practice.
> ...
> 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"?
It's hard to come out and say this, but Lynx does Accept: */*, assuming
that the user wants the data from any request. The user is promted wether
or not the data should be downloaded if not displayable. Correct content
handling for a client? Maybe not.
Further, if we move clients away from doing this type of thing, then
should a client be asking for the head and then ask if the user wants the
data before a full transaction? If so, shouldn't the mechanism be in libwww?
Garrett.
Trodden Soil
I am trodden soil.
Dust covers my face.
Soles crush my nature
Revealing a hard empty space.
Garrett Arch Blythe (913)864-0436
User Services Student Programmer/Consultant
University of Kansas Computer Center
<doslynx@falcon.cc.ukans.edu>