W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1996

Re: proposed HTTP changes for charset

From: Benjamin Franz <snowhare@netimages.com>
Date: Mon, 8 Jul 1996 07:09:40 -0700 (PDT)
To: "Roy T. Fielding" <fielding@liege.ICS.UCI.EDU>
Cc: Francois Yergeau <yergeau@alis.ca>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <Pine.LNX.3.93.960708063301.9727A-100000@ns.viet.net>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1050
On Fri, 5 Jul 1996, Roy T. Fielding wrote:

> I have already covered these questions ad-nauseum.
>   4) Labelling the charset with its real value if it is different than
>      iso-8859-1 *always* works, both in old an new practice, because
>      any user agent incapable of handling a charset value is also
>      incapable of handling a charset other than iso-8859-1.  The only
>      time problems occur is when iso-8859-1 data is labelled as such
>      and then delivered to an older client.

This isn't true. I was recently writing a chat CGI program and tried
labelling something as ISO-2022-JP. It caused the otherwise Japanese 
display capable browser client (MSIE 3.0b1) to choke. It refused to
display the charset labelled file, instead attempting to download to a
file. If I *didn't* label it I was fine. The issue of charset labelling
breaking browsers cannot be neatly shoved off that way. It breaks
non-latin1 1.0 browsers just as badly as latin1  1.0 browsers. If it is
unacceptable to mandate charset labelling becasue it breaks latin1
browsers - it is equally unacceptable to break non-latin 1 browsers.

I am trying to figure out why charset being a MUST for 1.1 is even an
issue at all.  Let's see if I have this right.

Case 1) A client *issues* a 1.1 request to a 1.0 server.

The server chokes on the 1.1 level and returns a 400 error.  Ok. No
problem the client can now try to back off to 1.0 - which won't be
labelled with a charset most likely. 

Case 2) A client issues a 1.1 request to a 1.1 server.

It gets a charset *always*. No problem - since there *ARE* no HTTP/1.1
browsers in existence today there is no compatiblity issue.

Case 3) A client issues a 1.0 request to a 1.1 server

Server serves up as a 1.0 server without charset labelling (same as
today's servers). No problem.

Case 4) A client issues a 1.1 request to a 1.1 server.

It gets a 1.1 responese including charset *always*. No problem.
Since there are no 1.1 browsers today, you can mandate charset
safely as far as browsers are concerned.

Ok. All of these cases work ok. So the problem has got to be when you
stick a proxy in the line. How does mandating charsets break proxies?
I don't see it.

Benjamin Franz
Received on Monday, 8 July 1996 07:14:33 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:17 UTC