Any way to invoke code from VCL after a request has been serviced?

[Guillaume Quintard]

Sorry to dig that one up, but I stumble upon it again, and it got me
thinking: can't we just put the point to req->err_code in priv? That's not
super clean, but from what I re-read in the code, it should still be there
when it's time to clean the priv.

-- 
Guillaume Quintard

On Tue, May 23, 2017 at 11:15 PM, Ryan Burn <rnickb731 at gmail.com> wrote:

> > When it comes to header manipulations (including method, status etc)
> > they are already logged so a VUT can already pick that up and save
> > some work from the VMOD.
>
> It doesn't need to just view the headers; it needs to add headers to
> encode the
> active span context. See
> http://opentracing.io/documentation/pages/api/cross-process-tracing.html
> And the active span needs to be started before those headers can be added.
>
> > I'm not familiar with OT but what I described is how Zipnish does its
> > tracing. Except that Zipnish relies on the X-Varnish header to get a
> > unique-ish id, so no blocking call needs to be made. So maybe they are
> > highly different systems, I chimed in because I saw a Zipkin example
> > while briefly skimming through the docs.
>
> Zipkin is a distributed tracing system that provides OpenTracing
> implementations, but Zipnish is just using it as a monitor for
> varnish. It's not doing context propagation. If you're only interested
> in monitoring varnish, that's fine; but if you want to see how a
> request is processed in an entire distributed system (i.e. not just
> varnish, but the backend servers it's sitting in front of or any other
> service that might be in front of varnish), then you need to do
> context propagation.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20180206/d1d7bdb7/attachment.html>