<div dir="ltr"><div><div>Some comments below.</div></div><div><br></div><div><div>> This laves only one "internal" error on the client side:</div><div>> Restarting too many times.   We will handle this by making</div>
<div>> an attempt to restart past $max_restarts turn into:</div><div>></div><div>>   return(synth(503));</div></div><div><br></div><div>Can we apply the same logic for 400s or anything that we cannot parse (talking about CVE-2013-4484 mostly here) ?</div>
<div>In some (most?) situations people might want to show a customised error page and not the 400 currently returned by varnish.</div><div><br></div><div>> If we get a reply from the backend, we got to vcl_backend_response{}</div>
<div>> which can return 'deliver', 'retry' or 'abandon'  (pass is done</div><div>> by setting beresp.do_pass, because it is orthogonal)</div><div><br></div><div>I believe you meant beresp.uncacheable here.<br>
</div><div><br></div><div>> I was proposed to make obj.* entirely read-only.</div><div><br></div><div>Question: in the new world if you want to, say do a redirect, where and which variable you'll need to set?</div>
<div>Currently this is done in vcl_error{} changing obj.http.Location and obj.status.</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Feb 17, 2014 at 8:56 AM, Poul-Henning Kamp <span dir="ltr"><<a href="mailto:phk@phk.freebsd.dk" target="_blank">phk@phk.freebsd.dk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Last wednesday I went to Oslo and tried to hammer out a plan for releasing<br>
4.0-R with the V-S crew.<br>
<br>
The big thing is documentation, there is a lot of docs to be written<br>
and you are all cordially invited to help out :-)<br>
<br>
We also hashed out a plan for the backend-fetch-retry-error issue that<br>
keeps confounding me, and I think it will hold up.<br>
<br>
On the client side:<br>
<br>
        vcl_error{} becomes vcl_synth{}<br>
<br>
        The client side alyways get an object back from a fetch,<br>
        fetch failures will be handled on the backend side.  The<br>
        object we get back may be a 503 and it may be a pass, but<br>
        it is an object.<br>
<br>
        This laves only one "internal" error on the client side:<br>
        Restarting too many times.   We will handle this by making<br>
        an attempt to restart past $max_restarts turn into:<br>
<br>
                return(synth(503));<br>
<br>
On the backend side:<br>
<br>
        vcl_backend_fetch{} Prepares the the request to be sent to<br>
        the backend.<br>
<br>
        If we get a reply from the backend, we got to vcl_backend_response{}<br>
        which can return 'deliver', 'retry' or 'abandon'  (pass is done<br>
        by setting beresp.do_pass, because it is orthogonal)<br>
<br>
        If we do not get a reply or if v_b_r returns 'abandon' we end up<br>
        in vcl_backend_error{}, which in the builtin-vcl creates a 503<br>
        pass error page like vcl_error{} does today.  Possible returns<br>
        are retry and deliver.<br>
<br>
        Too may retries take you to v_b_e{}.<br>
<br>
I was proposed to make obj.* entirely read-only.<br>
<br>
Changing obj.ttl was essentially done to hack up grace, and no longer<br>
makes any sense.<br>
<br>
Obj.hits and obj.last_use are of speculative use at best, mostly<br>
for debugging, and it's questionable if they should live on individual<br>
objects or on the objhdr in the first place.<br>
<br>
Making objects read/only once created, will allow us to implement<br>
more efficient stevedore modules (at least we think so).<br>
<br>
We also want to move the LRU processing into the stevedores, but<br>
that does not have to happen for 4.0, that can be done later.<br>
<br>
Martin promised to sort out the new tool-lib he made before 4.0<br>
<br>
X-Forward-For and Connection: close for pipe will be moved to<br>
C-code: They can be fixed in VCL if people have special requirements.<br>
<br>
I need to implement the acct/stats VSL records (per VDD13Q4 and<br>
subsequent email threads).<br>
<br>
Anything missing ?<br>
<br>
We're currently aiming at a release in the april 1st time frame.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
--<br>
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20<br>
phk@FreeBSD.ORG         | TCP/IP since RFC 956<br>
FreeBSD committer       | BSD since 4.3-tahoe<br>
Never attribute to malice what can adequately be explained by incompetence.<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>
</font></span></blockquote></div><br></div>