unsubscribe

[Zheng Liu]

On Tue, Dec 4, 2012 at 5:26 AM, <varnish-dev-request at varnish-cache.org>wrote:

> Send varnish-dev mailing list submissions to
>         varnish-dev at varnish-cache.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
> or, via email, send a message with subject or body 'help' to
>         varnish-dev-request at varnish-cache.org
>
> You can reach the person managing the list at
>         varnish-dev-owner at varnish-cache.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of varnish-dev digest..."
>
>
> Today's Topics:
>
>    1. Re: RFC 5861 support (Marcos Paulo Hack)
>    2. Re: RFC 5861 support (Andrea Campi)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 4 Dec 2012 12:58:47 +0000
> From: Marcos Paulo Hack <marcos.hack at abril.com.br>
> To: Andrea Campi <andrea.campi at zephirworks.com>
> Cc: "varnish-dev at varnish-cache.org" <varnish-dev at varnish-cache.org>
> Subject: Re: RFC 5861 support
> Message-ID:
>         <
> 34AEF30D921AD846A83E78166A8B45341B34ECD5 at ABRWPDAGDP04.gabril.com.br>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Andrea.
>
> On Dec 4, 2012, at 6:08 AM, Andrea Campi <andrea.campi at zephirworks.com
> <mailto:andrea.campi at zephirworks.com>>
>  wrote:
>
>
> On Tue, Dec 4, 2012 at 2:42 AM, Marcos Paulo Hack <
> marcos.hack at abril.com.br<mailto:marcos.hack at abril.com.br>> wrote:
> Hi Andrea.
>
> As discussed in IRC channel, the grace mode should be used to implement
> the stale-while-revalidate directive, but there is no easy (or even viable)
> way to implement stale-if-error using VLC.
>
> Do logs exist for that conversation? I would be interested in the
> rationale for that.
>
> I couldn't find the channel log anywhere so I attached here.
>
> At face value it sounds like a useful implementation of stale-if-error can
> be done in VCL using saint mode.
>
> Other than that, I'll probably end up doing a VMOD anyway.
>
> The only problem with stale-while-revalidate using grace mode is that it
> isn't really asynchronous as discussed here [1]. So a VMOD implementation
> should be required to be full compliance with the RFC.
>
>
> Looking at the RFC some more, I have some questions. I'll probably get in
> touch with the editor of the RFC:
>
> * I am unclear on whether this is intended for reverse proxies that can be
> considered "part of the application" or if remote proxies and user agents
> are allowed to use it too.
> The use of Cache-Control suggest the latter, but in that case I would like
> to see an implementation in a browser before I start sending these headers
> out in the wild. I realize user agents are free to show stale content
> anyway, but they usually don't.
> Vice versa, it looks like these extensions may be useful also in
> Surrogate-Control, where we can easily ensure they never make it past
> Varnish.
>
> * I don't like stale-if-error in a request. I won't comment on its useful
> from the point of view of the user agent (other than saying it would make
> for a complex UI).
> But from the point of view of Varnish, the only useful use case I can see
> is *reducing* the allowed staleness?since by definition it can't make it
> any longer than the time the object persists in the cache.
> If I were to implement this, I would just ignore this in requests.
>
> Thoughts? I'll probably start working on this and edge-arch over the next
> week, so any reasoned opinion is appreciated as it may very well save me
> time ;)
>
> Good questions. You should talk to Mark Nottingham, indeed.
>
> Just a side note: the folks of Traffic Server just finished their
> experimental implementation a month ago, maybe you can find some useful
> insights over there ;)
>
> [1]
> https://www.varnish-cache.org/lists/pipermail/varnish-misc/2012-March/021800.html
> [2]
> https://github.com/apache/trafficserver/tree/master/plugins/experimental/rfc5861
>
> Regards.
> Marcos
>
>
>
> AVISO LEGAL: Esta mensagem e arquivos podem conter informacoes
> confidenciais e ou legalmente protegidas.
> Caso tenha recebido por engano, favor devolve-la ao remetente e elimina-la
> do seu sistema, nao divulgando ou utilizando a totalidade ou parte desta
> mensagem ou dos documentos a ela anexados.
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://www.varnish-cache.org/lists/pipermail/varnish-dev/attachments/20121204/7be68fc7/attachment-0001.html
> >
> -------------- next part --------------
> An embedded and charset-unspecified text was scrubbed...
> Name: linpro_varnish_channel-RFC5861.txt
> URL: <
> https://www.varnish-cache.org/lists/pipermail/varnish-dev/attachments/20121204/7be68fc7/attachment-0001.txt
> >
>
> ------------------------------
>
> Message: 2
> Date: Tue, 4 Dec 2012 14:26:30 +0100
> From: Andrea Campi <andrea.campi at zephirworks.com>
> To: Marcos Paulo Hack <marcos.hack at abril.com.br>
> Cc: "varnish-dev at varnish-cache.org" <varnish-dev at varnish-cache.org>
> Subject: Re: RFC 5861 support
> Message-ID:
>         <
> CACXW+KH1ixaeV-8jVdSQBJN6E3ovU_P4nSyk8uiq-3syNHKeHg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Tue, Dec 4, 2012 at 1:58 PM, Marcos Paulo Hack
> <marcos.hack at abril.com.br>wrote:
>
> >  Hi Andrea.
> >
> >  On Dec 4, 2012, at 6:08 AM, Andrea Campi <andrea.campi at zephirworks.com>
> >  wrote:
> >
> > At face value it sounds like a useful implementation of stale-if-error
> can
> > be done in VCL using saint mode.
> >
> >  Other than that, I'll probably end up doing a VMOD anyway.
> >
> >
> >  The only problem with stale-while-revalidate using grace mode is that it
> > isn't really asynchronous as discussed here [1]. So a VMOD implementation
> > should be required to be full compliance with the RFC.
> >
>
>
> The RFC does say:
>
> indicates that it is fresh for 600 seconds, and it may continue to be
>    served stale for up to an additional 30 seconds while an asynchronous
>    validation is attempted.
>
>
> However later on:
>
>
>    Since asynchronous validation will only happen if a request occurs
>    after the response has become stale, but before the end of the stale-
>    while-revalidate window, the size of that window and the likelihood
>    of a request during it determines how likely it is that all requests
>    will be served without delay.  If the window is too small, or traffic
>    is too sparse, some requests will fall outside of it, and block until
>    the server can validate the cached response.
>
>
> The way I read this is that the RFC doesn't concern itself with telling us
> that we *must* make an asynchronous request.
> Instead, the assumed goal is to allow as many requests as possible to
> continue unimpeded.
>
> Let me turn this around: I'm not going to attempt to change the
> architecture of Varnish to do asynchronous background requests.
> Given that, would implementing the RFC still be useful?
> I think so, because it allows us to push responsibility for deciding how
> much grace to apply to an object out of the VCL and into the bbackend,
> where it belongs.
> Would such an implementation still conform to the RFC? I think so. If you
> tested this as a blackbox, all you would see if that one request will take
> longer, but other than that it would work as expected.
>
> Besides, when in doubt between perfect compliance with a standard some day
> in the future, or a 90% implementation that solves a real problem today,
> I'll pick the latter any day and twice on Sundays ;)
>
>
> Andrea
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://www.varnish-cache.org/lists/pipermail/varnish-dev/attachments/20121204/ead8e0e1/attachment.html
> >
>
> ------------------------------
>
> _______________________________________________
> varnish-dev mailing list
> varnish-dev at varnish-cache.org
> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
>
> End of varnish-dev Digest, Vol 81, Issue 4
> ******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-dev/attachments/20121204/e3a37968/attachment-0001.html>