RFC 5861 support

Marcos Paulo Hack marcos.hack at abril.com.br
Tue Dec 4 16:25:56 CET 2012


I agree, Andrea. Grace and saint modes should be enough to implement a very good approximation of the behaviour defined in the RFC right now and solve the majority of use cases, including mine :)

Thanks for your attention and I'll keep in touch to follow any progress about that.

Best regards.
Marcos


On Dec 4, 2012, at 11:26 AM, Andrea Campi <andrea.campi at zephirworks.com<mailto:andrea.campi at zephirworks.com>>
 wrote:




On Tue, Dec 4, 2012 at 1:58 PM, Marcos Paulo Hack <marcos.hack at abril.com.br<mailto:marcos.hack at abril.com.br>> wrote:
Hi Andrea.

On Dec 4, 2012, at 6:08 AM, Andrea Campi <andrea.campi at zephirworks.com<mailto: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


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/ec8b2541/attachment.html>


More information about the varnish-dev mailing list