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>