- From: W.Sylwestrzak@icm.edu.pl <wojsyl1@icm.edu.pl>
- Date: Wed, 11 Jun 1997 04:42:27 +0200 (MET DST)
- To: advax@triumf.ca
- Cc: http-wg@cuckoo.hpl.hp.com, ircache@nlanr.net
Andrew Daviel: > > 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. > > I don't think so ... If I have A.var, which redirects to > A.en.html, A.jp-jis.html, A.jp-eu.html, A.fr.html I have one > small uncacheable redirect, and 4 cacheable documents. The 4 documents > are all different, and have distinct URLs, so are cached independantly. I totally agree with your example. However I strongly feel that 'charset negotiation' should be approached differently than language and other stuff. Because various versions of the same document differing only in character encoding are effectively the same object and should not be cached, indexed etc. separately. > > 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). > > Nice idea; pity everyone's platform uses different coding :-( > (shift-jis, jis, euc-jp; koi-8, 8859-5, Windows-xxx etc etc.) > I think in some cases DOS, Windows, X11 and Mac are all different. I'm not knowledgeable about non-european sets, but for most central-eastern European language ISO-8859-2 would be sufficient (and browsers for most platforms accept it) - so why complicating this ? But perhaps this is wrong example. --wojtek
Received on Tuesday, 10 June 1997 19:44:34 UTC