Mailing List Archive

Already answered on varnish-dev.

DES
--
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no

In message <53C652A09719C54DA24741D0157CB2695FF981 at TFPRDEXS1.tf1.groupetf1.fr>,
"BUSTARRET, Jean-francois" writes:

>"If the no-cache directive does not specify a field-name, then a cache
>MUST NOT [...]

Varnish is not a cache in the RFC2616 sense. It more of an extension
of the web-server, which is probably best thought of as "a webserver
that picks up its contents with HTTP".

Therefore, a lot of what RFC2616 has to say about caches do not
apply to Varnish.

The key distinction is that a RFC2616 cache is not under the content
providers control, so it must follow whatever intructions he gives
in the HTTP headers, whereas Varnish is under his control and he
therefore has other means of instruction (notably VCL).

--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

Yet http://varnish.projects.linpro.no/wiki/FAQ says "Varnish was written from the ground up to be a high performance caching reverse proxy." Varnish is a cache, and should follow HTTP/1.1 RFCs.

http://varnish.projects.linpro.no/wiki/HTTPFeatures also references these features :
355 MUST NOT 14.9.1 cache responses with cache-control: private
356 MUST NOT 14.9.1 use responses with cache-control: no-cache to satisfy other requests without successful revalidation

I don't see a problem of having to have the Cache-control logic written in VCL, as long as :
- the default configuration uses it (or the vcl code is in the man pages, not in google).
- it is as fast as C code (vcl is compiled, so it's ok)
- I don't have to use regexps. For now, I have to use two of them : (obj.http.Pragma ~ "no-cache" || obj.http.Cache-Control ~ "no-cache" - I am not using Cache-control: private), but two strpos-like would do the job, with less overhead.

Jean-Fran?ois

> -----Message d'origine-----
> De : varnish-misc-bounces at projects.linpro.no
> [mailto:varnish-misc-bounces at projects.linpro.no] De la part
> de Poul-Henning Kamp
> Envoy? : lundi 19 novembre 2007 17:20
> ? : BUSTARRET, Jean-francois
> Cc : varnish-misc at projects.linpro.no
> Objet : Re: Support Cache-Control no-cache/private as per RFC2616 ?
>
> In message
> <53C652A09719C54DA24741D0157CB2695FF981 at TFPRDEXS1.tf1.groupetf1.fr>,
> "BUSTARRET, Jean-francois" writes:
>
> >"If the no-cache directive does not specify a field-name,
> then a cache
> >MUST NOT [...]
>
> Varnish is not a cache in the RFC2616 sense. It more of an
> extension of the web-server, which is probably best thought
> of as "a webserver that picks up its contents with HTTP".
>
> Therefore, a lot of what RFC2616 has to say about caches do
> not apply to Varnish.
>
> The key distinction is that a RFC2616 cache is not under the
> content providers control, so it must follow whatever
> intructions he gives in the HTTP headers, whereas Varnish is
> under his control and he therefore has other means of
> instruction (notably VCL).
>
> --
> Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
> phk at FreeBSD.ORG | TCP/IP since RFC 956
> FreeBSD committer | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by
> incompetence.
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at projects.linpro.no
> http://projects.linpro.no/mailman/listinfo/varnish-misc
>

In message <53C652A09719C54DA24741D0157CB2695FF997 at TFPRDEXS1.tf1.groupetf1.fr>,
"BUSTARRET, Jean-francois" writes:
>
>Yet http://varnish.projects.linpro.no/wiki/FAQ says "Varnish was written =
>from the ground up to be a high performance caching reverse proxy." =
>Varnish is a cache, and should follow HTTP/1.1 RFCs.

You're welcome to your opinion :-)

We belive we have good arguments for the choices we have made, and
as development continues, it is not inconceiveable that Varnish
might some time in the future grow a "act like an RFC2616 cache",
should somebody code the necessary changes or sponsor somebody
else to do so.

In the mean time, we try to get the maximum bang out of Varnish and
think we have made the correct call on this point.

One thing we have heard severalt times is that content providers
want to be able to use Cache-Control for client instructions and
not penalize their Varnish performance with its settings.

There is a draft floating around which defines a "Surrogate-Control"
along the lines of "Cache-Control" but it seems to have little
backing and even less use.

Poul-Henning

--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

"Poul-Henning Kamp" <phk at phk.freebsd.dk> writes:
> There is a draft floating around which defines a "Surrogate-Control"
> along the lines of "Cache-Control" but it seems to have little
> backing and even less use.

It has just as much backing and use as ESI; in fact, it is a
prerequisite for ESI.

DES
--
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no

"BUSTARRET, Jean-francois" <jfbustarret at wat.tv> writes:
> Yet http://varnish.projects.linpro.no/wiki/FAQ says "Varnish was
> written from the ground up to be a high performance caching reverse
> proxy." Varnish is a cache, and should follow HTTP/1.1 RFCs.

Excuse me, but who are you to tell us what Varnish is or is not? Do
you realize how arrogant that is?

That aside, you are trying to fit Varnish into an RFC2616 pigeonhole,
but there is no pigeonhole that fits - RFC2616 did not anticipate
anything like Varnish. There is a draft W3 specification, the Edge
Architecture Specification, which attempts to fill that hole, but it
is not widely known, so I'm not sure it would help much to write that
Varnish is an HTTP surrogate rather than an HTTP accelerator (I try to
avoid the term "reverse proxy").

DES
--
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no

I won't reply to the first part of DES message...

I understand the point, and, as I said before, I really like the VCL approach. The real problem is that, for a new varnish user, it is difficult to understand what varnish really is. A new user would read the FAQ and think that varnish is a reverse proxy, but, as said, it isn't (out of the box, I agree that a reverse proxy is only a few lines of VCL code away).

IMHO, this is mainly a documentation problem. Why not :
- remove the term "reverse proxy" from the FAQ and replace it by "HTTP Accelerator",
- describe exactly what/when varnish caches by default,
- describe how to build a RFC2616 reverse proxy, and bundle a sample vcl with varnish.

As Poul-Henning told, someone should contribute/sponsor this. Having more time than money (and feeling not 100% welcome here), I can write some documentation if you agree.

Jean-Fran?ois

> -----Message d'origine-----
> De : varnish-dev-bounces at projects.linpro.no
> [mailto:varnish-dev-bounces at projects.linpro.no] De la part de
> Manuel Amador (Rudd-O)
> Envoy? : mardi 20 novembre 2007 12:31
> ? : varnish-dev at projects.linpro.no
> Objet : Re: Support Cache-Control no-cache/private as per RFC2616 ?
>
> Do you really need to snap at contributors, Dag-Erling? I
> happen to agree with him in the sense that pulling Varnish
> (VCL or *not*) in the direction of a complete
> standards-compliant configuration-free smart Web accelerator
> is a very good idea.
>
> The grandfather poster may be a bit misguided as to what
> standards Varnish would need to comply to, but your comment
> would have easily been more constructive if you just had
> limited yourself to the Edge mention.
>
> And, of course, you are already publicly aware of my position
> regarding the matter.
>
> An idea: We need a matrix (OK, a nice table) or a decision
> tree of what actions Varnish should take by default, given a
> set of requests and content of varied freshness degrees.
> Once that work is done, moving VCL (and the default VCL
> config) in the direction that will allow us to actually
> produce that decision tree, should be much easier and clearer.
>
> El Mar 20 Nov 2007, Dag-Erling Sm?rgrav escribi?:
> > "BUSTARRET, Jean-francois" <jfbustarret at wat.tv> writes:
> > > Yet http://varnish.projects.linpro.no/wiki/FAQ says "Varnish was
> > > written from the ground up to be a high performance
> caching reverse
> > > proxy." Varnish is a cache, and should follow HTTP/1.1 RFCs.
> >
> > Excuse me, but who are you to tell us what Varnish is or is
> not? Do
> > you realize how arrogant that is?
> >
> > That aside, you are trying to fit Varnish into an RFC2616
> pigeonhole,
> > but there is no pigeonhole that fits - RFC2616 did not anticipate
> > anything like Varnish. There is a draft W3 specification, the Edge
> > Architecture Specification, which attempts to fill that
> hole, but it
> > is not widely known, so I'm not sure it would help much to
> write that
> > Varnish is an HTTP surrogate rather than an HTTP
> accelerator (I try to
> > avoid the term "reverse proxy").
> >
> > DES
>
>
>
> --
>
> Manuel Amador (Rudd-O) <rudd-o at rudd-o.com>
> Rudd-O.com - http://rudd-o.com/
> GPG key ID 0xC8D28B92 at http://wwwkeys.pgp.net/
>
> Now playing, courtesy of Amarok: Voodoo & Serano - Blood is
> pumping So this is it. We're going to die.
>

"BUSTARRET, Jean-francois" <jfbustarret at wat.tv> writes:
> IMHO, this is mainly a documentation problem. Why not :
> - remove the term "reverse proxy" from the FAQ and replace it by "HTTP Accelerator",
> - describe exactly what/when varnish caches by default,
> - describe how to build a RFC2616 reverse proxy, and bundle a sample vcl with varnish.
>
> As Poul-Henning told, someone should contribute/sponsor this. Having
> more time than money (and feeling not 100% welcome here), I can
> write some documentation if you agree.

Documentation is always welcome. The wiki needs a lot of work, and
both Poul-Henning and I have far too much to do (both with Varnish and
other projects) to be able to spend much time on it.

BTW, could I suggest that you subscribe to varnish-misc or varnish-dev
(or both) so I don't have to manually approve everything you send to
the list?

DES
--
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no

> -----Message d'origine-----
> De : Dag-Erling Sm?rgrav [mailto:des at linpro.no]
> Documentation is always welcome. The wiki needs a lot of
> work, and both Poul-Henning and I have far too much to do
> (both with Varnish and other projects) to be able to spend
> much time on it.

I'll send something next week on the list

> BTW, could I suggest that you subscribe to varnish-misc or
> varnish-dev (or both) so I don't have to manually approve
> everything you send to the list?

Sorry for that. I'll never get used to what Exchange does to emails... This should be ok.

Jean-Fran?ois

"BUSTARRET, Jean-francois" <jfbustarret at wat.tv> writes:
> Dag-Erling Sm?rgrav <des at linpro.no> writes:
> > BTW, could I suggest that you subscribe to varnish-misc or
> > varnish-dev (or both) so I don't have to manually approve
> > everything you send to the list?
> Sorry for that. I'll never get used to what Exchange does to
> emails... This should be ok.

No, you are posting from a different address than that with which you
subscribed. The easiest fix is probably to move your subscription
over to the address you are posting from. Alternatively, you can
subscribe with both addresses and disable one of them so you don't get
everything twice; you will then be able to post to the lists using
either address. Let me know which you prefer, and I'll take care of
it for you.

DES
--
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no