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

• Mail folder: WWW Talk Apr 94-present
• Next message: Sarr Blumson: "Re: Style Sheets for HTML "
• Previous message: Jonathan Abbey: "Re: Style Sheets for HTML"
• Reply: Jon P. Knight: "Re: Parameters in Content-Type: headers; what the???"

Errors-To: listmaster@www0.cern.ch
Date: Tue, 24 May 1994 23:15:26 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <22960.769813990@silky.cs.indiana.edu>
Errors-To: listmaster@www0.cern.ch
Reply-To: mvanheyn@cs.indiana.edu
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: Marc VanHeyningen <mvanheyn@cs.indiana.edu>
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Parameters in Content-Type: headers; what the???
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas

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>