In message <[email protected]>, Pabl o Borges writes:
>Could this be one topic for VUG3 ? :D Put it on the wiki and it will be... Poul-Henning > >Cheers, > >On Mon, Oct 4, 2010 at 10:34 AM, Nils Goroll <[email protected]> wrote: > >> Hi, >> >> I've had a first discussion with phk on IRC. IIUC, his main concern was >> that >> introducing the new states & VCL procedures would increase complexity and >> raise >> the entry barrier, in particular with regard to users wanting to (easily) >> customize the default vcl. >> >> I will elaborate on the reasons for the proposed solution. >> >> a) vcl_stale() >> -------------- >> >> The alternative we've discussed on IRC is to fall into vcl_miss(): If an >> obj >> eligible for refresh was found, default backend conditional request heade= >rs >> were >> added to bereq, and vcl_miss() would see obj. It wouldn't for the current >> case >> (a real miss). To avoid a backend conditional request, admins could remov= >e >> the >> conditional headers (If-...) from bereq. return(refresh) wouldn't exist. >> >> Here's my subjective perspective on why vcl_stale() would make sense: >> >> - Without vcl_stale(), the semantics of vcl_miss() would mean "I have not >> found >> an object eligible for delivery, but might have found one for refresh", >> which >> I believe will confuse users more than help. >> >> Mostly, this does open up a whole lot of oddities and questions: >> >> - vcl_miss would see obj only if it was a "stale miss" >> >> Odd: What would obj.status return for a "real miss"? >> >> - cnt_miss could prepare bereq.http.If-... headers only if it was a "sta= >le >> miss" >> >> - We would be able to return (deliver) for a "stale miss", but not for a >> real >> miss: What do we do here? We can't decide on the correctness of the VC= >L >> at compile time. Would return (deliver) fall back to a return (fetch) >> is it's a "real miss"? >> >> - Users would need to put more conditionals into vcl_miss for special >> handling >> of "stale" cases, =E0 la: >> >> if (obj) { >> # do stale case handling >> } else { >> # existing code >> } >> >> Depending on whether we want to default to the new or current behavior, a >> default vcl_stale() would look like: >> >> vcl_stale() { >> return (refresh); >> } >> >> or >> >> vcl_stale() { >> call vcl_miss; >> } >> >> >> >> If we put the mechanics into vcl_miss, retaining current behavior would >> need >> something like this with a full backend conditional: >> >> vcl_miss() { >> if (obj) { >> unset bereq.http.If-Match; >> unset bereq.http.If-Modified-Since; >> unset bereq.http.If-None-Match; >> unset bereq.http.If-Range; >> unset bereq.http.If-Unmodified-Since; >> } >> } >> >> >> My personal impression is that vcl_stale would help retain clarity rather >> than >> complicate things, in particular because it would help to limit additiona= >l >> processing to the cases when it's actually needed. >> >> b) vcl_refresh() >> ---------------- >> >> The alternative to vcl_refresh() would be to put additional logic into >> vcl_fetch(). >> >> Similar to the stale case, we would want to have access to the original >> object >> in the cache and the beresp from the refresh, so obj would be available >> only if >> vcl_refresh was entered with (beresp.status =3D=3D 304). >> >> >> >> We really want to retain clarity and not introduce unneeded additional >> complexity. I believe that introducing more VCL states and procedures wou= >ld >> help >> to achieve this, in particular because the preconditions for each case we= >re >> clear and visibility of a cache object was well defined. >> >> Thanks, Nils >> >> _______________________________________________ >> varnish-dev mailing list >> [email protected] >> http://lists.varnish-cache.org/mailman/listinfo/varnish-dev >> > >--0016362841567a3345049956f881 >Content-Type: text/html; charset=ISO-8859-1 >Content-Transfer-Encoding: quoted-printable > >Hey guys,<br><br>Could this be one topic for VUG3 ? :D<br><br>Cheers,<br><b= >r><div class=3D"gmail_quote">On Mon, Oct 4, 2010 at 10:34 AM, Nils Goroll <= >span dir=3D"ltr"><<a href=3D"mailto:[email protected]";>[email protected]= ></a>></span> wrote:<br> > ><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= >r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Hi,<br> ><br> >I've had a first discussion with phk on IRC. IIUC, his main concern was= > that<br> >introducing the new states & VCL procedures would increase complexity a= >nd raise<br> >the entry barrier, in particular with regard to users wanting to (easily)<b= >r> >customize the default vcl.<br> ><br> >I will elaborate on the reasons for the proposed solution.<br> ><br> >a) vcl_stale()<br> >--------------<br> ><br> >The alternative we've discussed on IRC is to fall into vcl_miss(): If a= >n obj<br> >eligible for refresh was found, default backend conditional request headers= > were<br> >added to bereq, and vcl_miss() would see obj. It wouldn't for the curre= >nt case<br> >(a real miss). To avoid a backend conditional request, admins could remove = >the<br> >conditional headers (If-...) from bereq. return(refresh) wouldn't exist= >.<br> ><br> >Here's my subjective perspective on why vcl_stale() would make sense:<b= >r> ><br> >- Without vcl_stale(), the semantics of vcl_miss() would mean "I have = >not found<br> > =A0an object eligible for delivery, but might have found one for refresh&q= >uot;, which<br> > =A0I believe will confuse users more than help.<br> ><br> > =A0Mostly, this does open up a whole lot of oddities and questions:<br> ><br> > =A0- vcl_miss would see obj only if it was a "stale miss"<br> ><br> > =A0 =A0Odd: What would obj.status return for a "real miss"?<br> ><br> > =A0- cnt_miss could prepare bereq.http.If-... headers only if it was a &qu= >ot;stale<br> > =A0 =A0miss"<br> ><br> > =A0- We would be able to return (deliver) for a "stale miss", bu= >t not for a real<br> > =A0 =A0miss: What do we do here? We can't decide on the correctness of= > the VCL<br> > =A0 =A0at compile time. Would return (deliver) fall back to a return (fetc= >h)<br> > =A0 =A0is it's a "real miss"?<br> ><br> >- Users would need to put more conditionals into vcl_miss for special handl= >ing<br> > =A0of "stale" cases, =E0 la:<br> ><br> > =A0if (obj) {<br> > =A0 =A0 =A0 =A0# do stale case handling<br> > =A0} else {<br> > =A0 =A0 =A0 =A0# existing code<br> > =A0}<br> ><br> >Depending on whether we want to default to the new or current behavior, a<b= >r> >default vcl_stale() would look like:<br> ><br> >vcl_stale() {<br> > =A0 =A0 =A0 =A0return (refresh);<br> >}<br> ><br> >or<br> ><br> >vcl_stale() {<br> > =A0 =A0 =A0 =A0call vcl_miss;<br> >}<br> ><br> ><br> ><br> >If we put the mechanics into vcl_miss, retaining current behavior would nee= >d<br> >something like this with a full backend conditional:<br> ><br> >vcl_miss() {<br> > =A0 =A0 =A0 =A0if (obj) {<br> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unset bereq.http.If-Match;<br> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unset bereq.http.If-Modified-Since;<br> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unset bereq.http.If-None-Match;<br> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unset bereq.http.If-Range;<br> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unset bereq.http.If-Unmodified-Since;<br> > =A0 =A0 =A0 =A0}<br> >}<br> ><br> ><br> >My personal impression is that vcl_stale would help retain clarity rather t= >han<br> >complicate things, in particular because it would help to limit additional<= >br> >processing to the cases when it's actually needed.<br> ><br> >b) vcl_refresh()<br> >----------------<br> ><br> >The alternative to vcl_refresh() would be to put additional logic into vcl_= >fetch().<br> ><br> >Similar to the stale case, we would want to have access to the original obj= >ect<br> >in the cache and the beresp from the refresh, so obj would be available onl= >y if<br> >vcl_refresh was entered with (beresp.status =3D=3D 304).<br> ><br> ><br> ><br> >We really want to retain clarity and not introduce unneeded additional<br> >complexity. I believe that introducing more VCL states and procedures would= > help<br> >to achieve this, in particular because the preconditions for each case were= ><br> >clear and visibility of a cache object was well defined.<br> ><br> >Thanks, Nils<br> ><br> >_______________________________________________<br> >varnish-dev mailing list<br> ><a href=3D"mailto:[email protected]";>varnish-...@varnish-cache.= >org</a><br> ><a href=3D"http://lists.varnish-cache.org/mailman/listinfo/varnish-dev"; tar= >get=3D"_blank">http://lists.varnish-cache.org/mailman/listinfo/varnish-dev<= >/a><br> ></blockquote></div><br> > >--0016362841567a3345049956f881-- > > >--===============4723512172216386742== >Content-Type: text/plain; charset="us-ascii" >MIME-Version: 1.0 >Content-Transfer-Encoding: 7bit >Content-Disposition: inline > >_______________________________________________ >varnish-dev mailing list >[email protected] >http://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev >--===============4723512172216386742==-- > -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [email protected] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. _______________________________________________ varnish-dev mailing list [email protected] http://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
