Hi! On Thu, Feb 05, 2009 at 02:34:19PM -0800, Nils wrote: > On Jan 20, 1:05 am, Anthony Bryan <[email protected]> wrote: [...] > > Eran started a thread about TCN on the HTTP list > > athttp://lists.w3.org/Archives/Public/ietf-http-wg/2009JanMar/0014.html > > (it wouldn't hurt the draft process for metalink people to be involved > > on there :) which includes Mark's reply: > > > > "To my knowledge, caching intermediaries haven't deployed it (i.e., > > they'll work with TCN, but they won't be able to serve negotiated > > requests from cache... somebody please correct me if I'm wrong).
One caching intermediary that perfectly supports this is Apache's disk_cache. As an example, you could load the mirror list from http://mirrors.opensuse.org/ and you'll get a gzipped version if your browser indicates so, and a plain version if not. Both are correctly cached according to the set Expires, and served from the cache. If you refresh them and cause a cache miss, you'll get a newly compressed, or newly generated plain, version from the origin server (which is the same Apache). (This is mostly used locallly, or for taking load of backends. And it has come a long way; Apache 2.2 required.) Another one is squid -- even old versions of squid support this just fine. Squid is much more common as intermediary proxy of course. There may be (many) other caching intermediary proxies that I am not aware of and haven't worked with -- I don't know. Anyhow, transparent negotiation of gzip encoding is so widely used that we can probably safely assume that it is handled in most cases. Too many highly popular web sites use it. And ISPs doing interception caching, and not doing it right in this regard, would pretty soon be out of business I think. > > I'm not sure about browser implementation, but I did a quick check of > > the request headers seen by a very high-traffic Web site, and a > > vanishingly small number contained the Negotiate header..." > > A usual website usually has not much to negotiate... > Likely only image representations, if there are even different > available. > > What you will likely see far more often is: > Vary: Accept-Encoding > A lot of sites offer either "plain" or gzip encoding. This is, as far > as I know, relatively widely deployed. > Hence I guess (but have no concrete data to undermine that guess) that > most proxies today in fact have no problem dealing with this. It is quite commonplace to add a Vary header Accept-Encoding when compressing content. It is not as well documented as it should be, but admins find out about it pretty quickly, usually. Luckily enough, it is pretty obvious and users notice that they get "garbage" soon, and the problem is easy enough to find out about, and the solution trivial. Peter -- Contact: [email protected] (a.k.a. [email protected]) #opensuse-mirrors on freenode.net Info: http://en.opensuse.org/Mirror_Infrastructure SUSE LINUX Products GmbH Research & Development --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Metalink Discussion" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/metalink-discussion?hl=en -~----------~----~----~----~------~----~------~--~---
