4.0 into the home-stretch

[Federico Schwindt]

Some comments below.

> This laves only one "internal" error on the client side:
> Restarting too many times.   We will handle this by making
> an attempt to restart past $max_restarts turn into:
>
>   return(synth(503));

Can we apply the same logic for 400s or anything that we cannot parse
(talking about CVE-2013-4484 mostly here) ?
In some (most?) situations people might want to show a customised error
page and not the 400 currently returned by varnish.

> If we get a reply from the backend, we got to vcl_backend_response{}
> which can return 'deliver', 'retry' or 'abandon'  (pass is done
> by setting beresp.do_pass, because it is orthogonal)

I believe you meant beresp.uncacheable here.

> I was proposed to make obj.* entirely read-only.

Question: in the new world if you want to, say do a redirect, where and
which variable you'll need to set?
Currently this is done in vcl_error{} changing obj.http.Location and
obj.status.



On Mon, Feb 17, 2014 at 8:56 AM, Poul-Henning Kamp <phk at phk.freebsd.dk>wrote:

>
> Last wednesday I went to Oslo and tried to hammer out a plan for releasing
> 4.0-R with the V-S crew.
>
> The big thing is documentation, there is a lot of docs to be written
> and you are all cordially invited to help out :-)
>
> We also hashed out a plan for the backend-fetch-retry-error issue that
> keeps confounding me, and I think it will hold up.
>
> On the client side:
>
>         vcl_error{} becomes vcl_synth{}
>
>         The client side alyways get an object back from a fetch,
>         fetch failures will be handled on the backend side.  The
>         object we get back may be a 503 and it may be a pass, but
>         it is an object.
>
>         This laves only one "internal" error on the client side:
>         Restarting too many times.   We will handle this by making
>         an attempt to restart past $max_restarts turn into:
>
>                 return(synth(503));
>
> On the backend side:
>
>         vcl_backend_fetch{} Prepares the the request to be sent to
>         the backend.
>
>         If we get a reply from the backend, we got to
> vcl_backend_response{}
>         which can return 'deliver', 'retry' or 'abandon'  (pass is done
>         by setting beresp.do_pass, because it is orthogonal)
>
>         If we do not get a reply or if v_b_r returns 'abandon' we end up
>         in vcl_backend_error{}, which in the builtin-vcl creates a 503
>         pass error page like vcl_error{} does today.  Possible returns
>         are retry and deliver.
>
>         Too may retries take you to v_b_e{}.
>
> I was proposed to make obj.* entirely read-only.
>
> Changing obj.ttl was essentially done to hack up grace, and no longer
> makes any sense.
>
> Obj.hits and obj.last_use are of speculative use at best, mostly
> for debugging, and it's questionable if they should live on individual
> objects or on the objhdr in the first place.
>
> Making objects read/only once created, will allow us to implement
> more efficient stevedore modules (at least we think so).
>
> We also want to move the LRU processing into the stevedores, but
> that does not have to happen for 4.0, that can be done later.
>
> Martin promised to sort out the new tool-lib he made before 4.0
>
> X-Forward-For and Connection: close for pipe will be moved to
> C-code: They can be fixed in VCL if people have special requirements.
>
> I need to implement the acct/stats VSL records (per VDD13Q4 and
> subsequent email threads).
>
> Anything missing ?
>
> We're currently aiming at a release in the april 1st time frame.
>
>
> --
> 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.
>
> _______________________________________________
> varnish-dev mailing list
> varnish-dev at varnish-cache.org
> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-dev/attachments/20140218/70ce0c1c/attachment.html>