- From: Wojtek Sylwestrzak <W.Sylwestrzak@icm.edu.pl>
- Date: Sun, 8 Jun 1997 15:05:30 +0200 (MET DST)
- To: "David W. Morris" <dwm@xpasc.com>
- Cc: W.Sylwestrzak@icm.edu.pl, dave@srce.hr, martin@mrrl.lut.ac.uk, http-wg@cuckoo.hpl.hp.com, ircache@nlanr.net
David W. Morris: > > Sorry, it is the client's resonsiblity to declare what is is capabile of. > It is the responsiblity of the server to deliver to the client content > that the client is able to understand, only then is it the client's > responsiblity to process it correctly. > Well ... , yes. We are talking about different things here. You write about content negotiation as in HTTP/1.1 while my comment was about the current practice. I should have been clearer about this. The intention of the document is I guess more practical recommendations than copying parts of HTTP/1.1 specs. Unfortunately most of the servers practicing this today try to perform a 'naive' content negotiation, which effectively uses redirects to other urls. This is of course wrong, because it unnecessarily expands the url addressing space, thus making caching less effective. Most of the contemporary clients are able to convert character encoding on the fly, so that the rendered document is presented to the reader with the font sets locally available. >From the caching point of view it would be a very good practice for the clients to request/expect a single, standard charset for a given language (considered being a 'transport' charset). I believe this problem is underestimated in countries, where charset requirements are satisfied by ISO-8859-1. Thanks, --wojtek
Received on Sunday, 8 June 1997 13:27:10 UTC