Support Cache-Control no-cache/private as per RFC2616 ?

[Mark Nottingham]

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       mnot at yahoo-inc.com