Parameters in Content-Type: headers; what the???

Marc VanHeyningen (mvanheyn@cs.indiana.edu)
Tue, 24 May 1994 16:13:10 -0500


Over the course of trying to figure out how to more effectively handle
MIME information within the context of WWW, I discovered just how
depressingly far apart these two worlds are.

Consider the following HTTP response:

HTTP/1.0 200 Document follows
MIME-version: 1.0
Content-type: text/plain

This is text in us-ascii; just testing.

Perfectly reasonable. Now, suppose we tweak it ever so slightly:

HTTP/1.0 200 Document follows
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii

This is text in us-ascii; just testing.

It works in exactly the same way, right? After all, the default
charset of text/plain must be either US-ASCII (the MIME default) or a
superset of it (ISO-Latin-1, I guess.) Section 2.4.4 of the HTTP spec
explicitly permits, even encourages, use of standard MIME parameters
to further specify the content-type.

Unfortunately, it doesn't work that way...

- Mosaic for UNIX: Does not display, but instead prompts the user to
save in a file as an unrecognized content-type
- Lynx: prompts the user to save in a file
- WWW Line Mode Browser: prompts to save in file
- TkWWW: Gives some funky error about a missing parameter and stays
on the current page
- Mosaic for Mac: Does the right thing!

If anyone wants to test this on their browser, the URL for the test
document I used is http://www.cs.indiana.edu/test.params and should
still be there. Varying things like the case of US-ASCII did not
appear to make a difference, although it's supposed to be
case-insensitive anyway.

It appears as though either:

- I am misreading the spec, and parameters specifying the character
set should not be used for text/plain objects
- Most of the existing browsers are broken; servers don't generate
parameters, so browsers don't bother to handle them properly even
though they're in the spec

So, which is it? And what do we do about it?

- Marc

--
<A HREF="http://www.cs.indiana.edu/hyplan/mvanheyn.html">Marc VanHeyningen</A>