I brought up the same issue that the original posted did a while back, only to be rebuffed in a similar manner.
I'd suggest that the problem here is one of terminology. Defining what Varnish does using HTTP terms is at best murky, so extra care needs to be taken so that users aren't misled (intentionally or not). This situation is what caused the caching industry to start using the term "surrogate" about six or seven years ago. See <http:// www.mnot.net/papers/wcw5-surrogates.pdf>. After some initial activity, interest waned, because the different players couldn't come to any substantial agreement about what a surrogate was, how to control it, etc.; the most substantial effort was ESI, and as has been pointed out, it was pretty watered down. Still, I think it's important to distinguish what Varnish does from a "normal" HTTP cache, especially since most other "HTTP Accelerators" and "reverse proxies" *do* conform to RFC2616 in most ways, because they're usually based upon HTTP proxy caches, rather than written from the ground up as a accelerator / surrogate. On 2007/11/21, at 4:54 AM, Poul-Henning Kamp wrote: > The only truly precise way to characterize varnish, IMO, is "A > webserver that uses HTTP to get at its content". This is a good characterisation. It would probably be more correct to say "gateway" than "webserver", but most casual readers won't know what that means. Cheers, -- Mark Nottingham [EMAIL PROTECTED] _______________________________________________ varnish-dev mailing list varnish-dev@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev