<div dir="ltr">You meant vcl_backend_response, right?<br><br>Actually there is yet another reason to do it in C. <br><br>If
 we were going to do it in the builtin vcl people wanting to override 
this value would need to either return early or fiddle with the header.</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 28, 2014 at 7:26 AM, Nils Goroll <span dir="ltr"><<a href="mailto:slink@schokola.de" target="_blank">slink@schokola.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 27/08/14 23:34, Geoff Simmons wrote:<br>
> I think I'm unsure about what we're striving for in Varnish 4 --<br>
> wasn't the goal to move as much caching policy as possible out to VCL,<br>
> with good defaults in builtin.vcl?<br>
<br>
</div>I see a bit of a tendency that we are moving towards having C code provide<br>
good/better defaults, still allowing VCL to modify them.<br>
<br>
This definitely is the case with fgs' proposed patch, vcl_backend_fetch still<br>
has the final word.<br>
<br>
But, yes, s-w-r can be done in VCL already (and it really is a good question if<br>
we shold just add it to the builtin.vcl). s-i-e, I think, needs additional C<br>
support to allow for a VCL implementation (see my post "restarting for bad<br>
synchronous responses").<br>
<br>
<side_note><br>
Some header mangling (Vary, Etag) we are doing in fetch processors at the moment<br>
is the exact contrary - VCL control is reduced (limited to vcl_deliver) until we<br>
get explicit fetch processor pushes (which phk is planning for).<br>
</side_note><br>
<span class="HOEnZb"><font color="#888888"><br>
Nils<br>
</font></span></blockquote></div><br></div>