On Tue, Dec 4, 2012 at 5:26 AM, <[email protected]>wrote:
> Send varnish-dev mailing list submissions to > [email protected] > > 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 > [email protected] > > You can reach the person managing the list at > [email protected] > > 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 <[email protected]> > To: Andrea Campi <[email protected]> > Cc: "[email protected]" <[email protected]> > Subject: Re: RFC 5861 support > Message-ID: > < > 34aef30d921ad846a83e78166a8b45341b34e...@abrwpdagdp04.gabril.com.br> > Content-Type: text/plain; charset="utf-8" > > Hi Andrea. > > On Dec 4, 2012, at 6:08 AM, Andrea Campi <[email protected] > <mailto:[email protected]>> > wrote: > > > On Tue, Dec 4, 2012 at 2:42 AM, Marcos Paulo Hack < > [email protected]<mailto:[email protected]>> 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 <[email protected]> > To: Marcos Paulo Hack <[email protected]> > Cc: "[email protected]" <[email protected]> > Subject: Re: RFC 5861 support > Message-ID: > < > cacxw+kh1ixaev-8jvdsqbjn6e3ovu_p4nsyk8uiq-3synhk...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > On Tue, Dec 4, 2012 at 1:58 PM, Marcos Paulo Hack > <[email protected]>wrote: > > > Hi Andrea. > > > > On Dec 4, 2012, at 6:08 AM, Andrea Campi <[email protected]> > > 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 > [email protected] > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev > > End of varnish-dev Digest, Vol 81, Issue 4 > ****************************************** >
_______________________________________________ varnish-dev mailing list [email protected] https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
