<br><br><div class="gmail_quote">On Tue, Dec 4, 2012 at 5:26 AM, <span dir="ltr"><<a href="mailto:varnish-dev-request@varnish-cache.org" target="_blank">varnish-dev-request@varnish-cache.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Send varnish-dev mailing list submissions to<br>
<a href="mailto:varnish-dev@varnish-cache.org">varnish-dev@varnish-cache.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev" target="_blank">https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:varnish-dev-request@varnish-cache.org">varnish-dev-request@varnish-cache.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:varnish-dev-owner@varnish-cache.org">varnish-dev-owner@varnish-cache.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of varnish-dev digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: RFC 5861 support (Marcos Paulo Hack)<br>
2. Re: RFC 5861 support (Andrea Campi)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Tue, 4 Dec 2012 12:58:47 +0000<br>
From: Marcos Paulo Hack <<a href="mailto:marcos.hack@abril.com.br">marcos.hack@abril.com.br</a>><br>
To: Andrea Campi <<a href="mailto:andrea.campi@zephirworks.com">andrea.campi@zephirworks.com</a>><br>
Cc: "<a href="mailto:varnish-dev@varnish-cache.org">varnish-dev@varnish-cache.org</a>" <<a href="mailto:varnish-dev@varnish-cache.org">varnish-dev@varnish-cache.org</a>><br>
Subject: Re: RFC 5861 support<br>
Message-ID:<br>
<<a href="mailto:34AEF30D921AD846A83E78166A8B45341B34ECD5@ABRWPDAGDP04.gabril.com.br">34AEF30D921AD846A83E78166A8B45341B34ECD5@ABRWPDAGDP04.gabril.com.br</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi Andrea.<br>
<br>
On Dec 4, 2012, at 6:08 AM, Andrea Campi <<a href="mailto:andrea.campi@zephirworks.com">andrea.campi@zephirworks.com</a><mailto:<a href="mailto:andrea.campi@zephirworks.com">andrea.campi@zephirworks.com</a>>><br>
wrote:<br>
<br>
<br>
On Tue, Dec 4, 2012 at 2:42 AM, Marcos Paulo Hack <<a href="mailto:marcos.hack@abril.com.br">marcos.hack@abril.com.br</a><mailto:<a href="mailto:marcos.hack@abril.com.br">marcos.hack@abril.com.br</a>>> wrote:<br>
Hi Andrea.<br>
<br>
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.<br>
<br>
Do logs exist for that conversation? I would be interested in the rationale for that.<br>
<br>
I couldn't find the channel log anywhere so I attached here.<br>
<br>
At face value it sounds like a useful implementation of stale-if-error can be done in VCL using saint mode.<br>
<br>
Other than that, I'll probably end up doing a VMOD anyway.<br>
<br>
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.<br>
<br>
<br>
Looking at the RFC some more, I have some questions. I'll probably get in touch with the editor of the RFC:<br>
<br>
* 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.<br>
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.<br>
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.<br>
<br>
* 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).<br>
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.<br>
If I were to implement this, I would just ignore this in requests.<br>
<br>
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 ;)<br>
<br>
Good questions. You should talk to Mark Nottingham, indeed.<br>
<br>
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 ;)<br>
<br>
[1] <a href="https://www.varnish-cache.org/lists/pipermail/varnish-misc/2012-March/021800.html" target="_blank">https://www.varnish-cache.org/lists/pipermail/varnish-misc/2012-March/021800.html</a><br>
[2] <a href="https://github.com/apache/trafficserver/tree/master/plugins/experimental/rfc5861" target="_blank">https://github.com/apache/trafficserver/tree/master/plugins/experimental/rfc5861</a><br>
<br>
Regards.<br>
Marcos<br>
<br>
<br>
<br>
AVISO LEGAL: Esta mensagem e arquivos podem conter informacoes confidenciais e ou legalmente protegidas.<br>
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.<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://www.varnish-cache.org/lists/pipermail/varnish-dev/attachments/20121204/7be68fc7/attachment-0001.html" target="_blank">https://www.varnish-cache.org/lists/pipermail/varnish-dev/attachments/20121204/7be68fc7/attachment-0001.html</a>><br>
-------------- next part --------------<br>
An embedded and charset-unspecified text was scrubbed...<br>
Name: linpro_varnish_channel-RFC5861.txt<br>
URL: <<a href="https://www.varnish-cache.org/lists/pipermail/varnish-dev/attachments/20121204/7be68fc7/attachment-0001.txt" target="_blank">https://www.varnish-cache.org/lists/pipermail/varnish-dev/attachments/20121204/7be68fc7/attachment-0001.txt</a>><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Tue, 4 Dec 2012 14:26:30 +0100<br>
From: Andrea Campi <<a href="mailto:andrea.campi@zephirworks.com">andrea.campi@zephirworks.com</a>><br>
To: Marcos Paulo Hack <<a href="mailto:marcos.hack@abril.com.br">marcos.hack@abril.com.br</a>><br>
Cc: "<a href="mailto:varnish-dev@varnish-cache.org">varnish-dev@varnish-cache.org</a>" <<a href="mailto:varnish-dev@varnish-cache.org">varnish-dev@varnish-cache.org</a>><br>
Subject: Re: RFC 5861 support<br>
Message-ID:<br>
<<a href="mailto:CACXW%2BKH1ixaeV-8jVdSQBJN6E3ovU_P4nSyk8uiq-3syNHKeHg@mail.gmail.com">CACXW+KH1ixaeV-8jVdSQBJN6E3ovU_P4nSyk8uiq-3syNHKeHg@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
On Tue, Dec 4, 2012 at 1:58 PM, Marcos Paulo Hack<br>
<<a href="mailto:marcos.hack@abril.com.br">marcos.hack@abril.com.br</a>>wrote:<br>
<br>
> Hi Andrea.<br>
><br>
> On Dec 4, 2012, at 6:08 AM, Andrea Campi <<a href="mailto:andrea.campi@zephirworks.com">andrea.campi@zephirworks.com</a>><br>
> wrote:<br>
><br>
> At face value it sounds like a useful implementation of stale-if-error can<br>
> be done in VCL using saint mode.<br>
><br>
> Other than that, I'll probably end up doing a VMOD anyway.<br>
><br>
><br>
> The only problem with stale-while-revalidate using grace mode is that it<br>
> isn't really asynchronous as discussed here [1]. So a VMOD implementation<br>
> should be required to be full compliance with the RFC.<br>
><br>
<br>
<br>
The RFC does say:<br>
<br>
indicates that it is fresh for 600 seconds, and it may continue to be<br>
served stale for up to an additional 30 seconds while an asynchronous<br>
validation is attempted.<br>
<br>
<br>
However later on:<br>
<br>
<br>
Since asynchronous validation will only happen if a request occurs<br>
after the response has become stale, but before the end of the stale-<br>
while-revalidate window, the size of that window and the likelihood<br>
of a request during it determines how likely it is that all requests<br>
will be served without delay. If the window is too small, or traffic<br>
is too sparse, some requests will fall outside of it, and block until<br>
the server can validate the cached response.<br>
<br>
<br>
The way I read this is that the RFC doesn't concern itself with telling us<br>
that we *must* make an asynchronous request.<br>
Instead, the assumed goal is to allow as many requests as possible to<br>
continue unimpeded.<br>
<br>
Let me turn this around: I'm not going to attempt to change the<br>
architecture of Varnish to do asynchronous background requests.<br>
Given that, would implementing the RFC still be useful?<br>
I think so, because it allows us to push responsibility for deciding how<br>
much grace to apply to an object out of the VCL and into the bbackend,<br>
where it belongs.<br>
Would such an implementation still conform to the RFC? I think so. If you<br>
tested this as a blackbox, all you would see if that one request will take<br>
longer, but other than that it would work as expected.<br>
<br>
Besides, when in doubt between perfect compliance with a standard some day<br>
in the future, or a 90% implementation that solves a real problem today,<br>
I'll pick the latter any day and twice on Sundays ;)<br>
<br>
<br>
Andrea<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://www.varnish-cache.org/lists/pipermail/varnish-dev/attachments/20121204/ead8e0e1/attachment.html" target="_blank">https://www.varnish-cache.org/lists/pipermail/varnish-dev/attachments/20121204/ead8e0e1/attachment.html</a>><br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
varnish-dev mailing list<br>
<a href="mailto:varnish-dev@varnish-cache.org">varnish-dev@varnish-cache.org</a><br>
<a href="https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev" target="_blank">https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev</a><br>
<br>
End of varnish-dev Digest, Vol 81, Issue 4<br>
******************************************<br>
</blockquote></div><br>