Testing Varnish

[Mark Nottingham]

On 2006/09/21, at 3:07 AM, Poul-Henning Kamp wrote:

> In message <E077482A-817A-4F54-A91A-C74AA34FD7FC at yahoo-inc.com>,  
> Mark Nottingha
> m writes:
>
>>> Varnish is not a proxy in the RFC2616 sense.  Varnish
>>> is an origin server.  An origin server which gets its contents
>>> using HTTP, but an origin server nontheless.
>>
>> That's a gateway, a.k.a. surrogate, a.k.a. reverse proxy.
>
> In RFC2616 context, Varnish is an origin server and a client, but
> it is not a proxy or a gateway.  Varnish is designed and built to
> be able to violate the semantic transparancy requirement for both
> of those.

Semantic transparency requirements are placed on caches, not gateways  
(or proxies, for that matter). "Reverse proxies," "accelerators,"  
"surrogates," most "CDNs" and similar systems are all gateways; they  
act as the origin server, from the client's point of view. Most of  
them have caches that aren't semantically transparent, because  
they've been configured (either directly, or with protocol  
extensions) to do things beyond "normal" HTTP.

> Therefore Varnish will look a lot like a proxy or gateway when you
> look at it first time.  But hopefully it will be much more than
> that to you, once you get to know it better.

I think this is a good expression of my concern. Most products like  
Varnish start from a base of being a conformant HTTP cache, and build  
extensions and modifications on top of that. If that isn't the  
intent, it needs to be said very clearly.

> All that however, does not change the fact that in the separate
> roles of client and origin server, Varnish should comply with
> RFC2616 to the extent possible, reasonable and productive.

That's good to hear. There seem to be a number of HTTP violations  
(that aren't specific to proxies) in Varnish; again, I'd encourage  
you to talk to the Measurement Factory folks and make their tests (or  
something like them) part of your QA suite.

Cheers,

--
Mark Nottingham
mnot at yahoo-inc.com