Elaborating on proposed vcl_stale() and vcl_refresh() // Proposal/specs for backend conditional requests / aka "GET If-Modified-Since" (GET IMS))
Poul-Henning Kamp
phk at phk.freebsd.dk
Sat Jan 8 20:44:47 CET 2011
In message <AANLkTikXNcW_PEqQoc_+ceV-fi5+AQ3ib4ubGvEnXP5O at mail.gmail.com>, 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 <slink at schokola.de> 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
>> varnish-dev at varnish-cache.org
>> 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:slink at schokola.de">slink at schokola.de=
></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:varnish-dev at varnish-cache.org">varnish-dev at 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
>varnish-dev at varnish-cache.org
>http://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
>--===============4723512172216386742==--
>
--
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.
More information about the varnish-dev
mailing list