- From: Erik van der Poel <erik@netscape.com>
- Date: Wed, 03 May 95 22:14:40 -0700
- To: Glenn Adams <glenn@stonehand.com>
- Cc: erik@netscape.com, html-wg@oclc.org, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
> So I'm asking if it's necessary to "negotiate" the absence/presence of the > charset parameter, because I'm worried that older clients may not be able > to handle content-type headers that include the charset parameter. > >There is already a means for such a negotiation; namely, the use of >a Simple-Request vs. a Full-Request. A Full-Request request that its >sender be capable of interpreting at least HTTP/1.0. Since the CHARSET >parameter on the content media type is specified by HTTP/1.0, then >the use of a Full-Request says that you must, at a minimum, be able to >parse such this parameter. [Note that this doesn't mean you have to >either interpret or make use of the parameter.] > >If a client is sending a Full-Request and cannot parse the parameter, then >it is broken and should be replaced. If many people are currently using clients that send Full Requests but can't parse the charset parameter, then getting the servers to simply add the charset will cause problems for all those people. Hey, why don't you try an experiment? You can get your hands on the server that has the Unicode documents (www.unicode.org), right? Change that server so that it adds "charset=us-ascii" or "charset=iso-8859-1" to the content-type line, and then wait and see how many people (if any) complain. Erik
Received on Wednesday, 3 May 1995 22:17:36 UTC