ulterior motive [was: Re: default return is "text/html"?]

Rick Troth (troth@rice.edu)
Tue, 19 Jul 1994 23:16:38 +0200

Trying to keep the talk technical ...

I think the consensus agrees that the web is more than just
HTTP, more then just Mosaic, Lynx, and friends, more then just HTML.
I mentioned an app I call 'webcat'. This is a generic "go fetch it"
tool for retrieving (and storing?) any URL-specifiable object.

On Tue, 19 Jul 1994, Daniel W. Connolly wrote:

> [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. ]

Webcat has only existed for a couple of months, so I don't
know if I've ever had it hit on an HTTP/0.9 server. It *does* use
the simplest GET, not HTTP/1.0. But ...

If what I want to do is grab some C source, I certainly
won't want that "<PLAINTEXT>" at the start! So if it's "plain text",
I don't want SGML thrown in purely for the sake of some viewer.
I want the plain text object sent as CR/LF text across the wire.
I just might want to do something with this object OTHER THAN view it.

If webcat were up to HTTP/1.0, then this potential problem
might never surface. (so far, I guess I've just been lucky)
Webcat knows about two kinds of objects: plain text and binary.
If some viewer/browser were to read a file that had been retrieved by
webcat, it would probably be a plain text object and the viewer would
have to make some sensible determination based on the presense, or lack,
of <html>, <!DOCTYPE...>, etc. No? This is what happens if you run
one of these browsers on a local file. This to me suggests that viewers
have a little more smarts, not just rely on defaults and HTTP headers.

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

I think this thread started because certain client(s)
apparently don't make "the right" assumption in this case. It's been
suggested that that's a different issue, not a protocol problem.

> 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'm kinda thinking that there should be. But if there is,
I don't want it to wind-up in the main stream. Ie: I don't want the
error message (text/html) where I expected a GIF (image/gif).
(argument for fixing my app, I'm sure)

> I realize that every HTTP client must support text/html and text/plain,
> but must every object be available as one of those?

Certainly not.

> Dan

-- 
Rick Troth <troth@rice.edu>, Rice University, Information Systems