> > Two comments to the current discussion:
> >
> > 1) Take a look at the specs at
> >
> > http://info.cern.ch/hypertext/WWW/Protocols/HTTP/Object_Headers.html
> >
> > They say the following about Content-Type:
> >
> > "As defined in MIME..."
> >
> > Now take a look at the MIME spec, rfc1521: about unknown
> > content-types:
> >
> > When a mail reader encounters mail with an unknown Content-type
> > value, it should generally treat it as equivalent to
> > "application/octet-stream", as described later in this document.
> >
> > So my conclusion is that the specs _do_ say how to handle the situation!
>
> Actually, the question here is not what to do if the Content-type is
> *unknown* -- we're discussing what to do if it is *missing*. This is
> also covered by MIME:
>
> Default RFC 822 messages are typed by this protocol as plain
> text in the US-ASCII character set, which can be explicitly
> specified as "Content-type: text/plain; charset=us-ascii".
> If no Content-Type is specified, either by error or by an
> older user agent, this default is assumed.
>
> > 2) In my opinion a missing content-type is equivalent to an unknown
> > content-type. I think it is a very narrow solution to assume that
> > everything unknown is HTML (or plain text) - this does not comply
> > with the normal level of abstraction in HTTP. The right thing
> > for the client to do is to treat it as "application/octet-stream"
> > and then dump the whole thing to a local file for further processing.
>
> I disagree -- a missing content-type is probably caused by a careless
> server (or CGI script), while an unknown one probably means that your
> client software (or its .mailcap file) has to be upgraded. Note that
> if the content-type is specified as foo/bar, where foo is a known type
> but bar is an unknown subtype of foo, the client should not default to
> application/octet-stream but to something dependent on foo -- e.g. for
> text/bar, text/plain should be assumed.
Okay, great and fine. We may actually have a definition at hand that
everyone should conform to.
I hate to do this, but if NCSA doesn't support it, then I get a load of
mail questioning why it won't work in Lynx. I'm not up to it, especially
when all I have to do to avoid the problem is change one line of code.
Standard or not, "text/html" may indeed be the best choice for a client.
The user base has sorely misused this inconsistancy with this vague
standard by noticing it's possible through Mosaic.
Compliance to a standard is indeed a great factor.
Compliance to my users' requests, because they simply want it, is also a
great factor.
In closing,
I am in support of application/octet-stream.
I've noticed sometimes that the content type of my mail messages will be
missing, and my reader tells me that it can't handle it (though it is
text/plain in actuallity), but that's not the mail reader's problem --
Let's put the responsibility of the screw ups where they need to belong.
This will make it quite clear to those testing their scripts and
servers that there is something wrong with the content-type they are
sending and not the client's ability to render text/*.
I want to plead the writers of the cgi-bin scripts and of the server
headers to correctly support the content type.
If you don't, then I will forever be receiving mail asking why their
Mosaic can but their Lynx can't; knowing that not one of them will write
NCSA saying "hey, you didn't parse your content-type correctly!"
Reality bites,
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>