V4 VCL roadmappery...

[sky at crucially.net]

But wouldn't you want to know what the backend thinks before you return stale?

IE, would return stale make more sense in fetch or error?
------Original Message------
From: Poul-Henning Kamp
To: Artur Bergman
Cc: varnish-dev at varnish-cache.org
Subject: Re: V4 VCL roadmappery...
Sent: Apr 7, 2013 13:43


> If you get a 304 from origin on a IMS to origin? Where would you end up. 

The bits on this diagram is all on the "client-side" of things.

The places where you see "fetch" we will (mostly) fork another thread
to do the actual fetching. (exception: pass ?)

If we have an expired obj ("exp_obj"), we'll pass that to the thread,
that will enable it to do conditional fetch (will do by default) and
if we get 304 back well stitch the exp_obj's body into the new object.

> And why would you want to return stale from lookup? (I feel like I am
> missing part of the puzzle)

That's basically what "grace" does today, only now we expose that
decision in VCL.

The default.vcl will look something like:

	sub vcl_lookup {
	    if (obj.uncacheable) {
		return (pass);
	    }
	    if (obj.ttl >= 0s) {
		return (deliver);
	    }
	    if (obj.ttl + obj.grace > 0s) {
		return (stale);
	    }
	    return (fetch);
	}

(input very welcome!)

> And is exp-obj the stale object?

Yes.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

Sent via BlackBerry by AT&T