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