4.0 into the home-stretch

[Poul-Henning Kamp]

In message <CAJV_h0bay_Z2vycfDyZ64E_Jw723CE8_wABOZegVDTYaMk06Cg at mail.gmail.com>
, Federico Schwindt writes:

>> 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) ?

As a result of that CVE, I took the decision that if Varnish cannot
parse the complete request it is not safe to call VCL with partial
information.

>In some (most?) situations people might want to show a customised error
>page and not the 400 currently returned by varnish.

I do appreciate that, but seriously:  Who but script-kiddie robots
get 400 in the first place ?

And if they get 400 on one transaction, what reason do we have to
belive they will not also get it for any other transaction ?

>> 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.

yes :-)

>> 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.

vcl_error{} becomes vcl_synth{} for just that kind of job.

-- 
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.