[master] 4ebc3cfec Make it possible to override the initial digest, and explain in a comment why it is not necessary.

[Poul-Henning Kamp]

--------
Nils Goroll writes:

>> But for all I care we can add a feature-flag, so allowing hash_data{} in
>> vcl_recv{} must be explicitly configured, that way nobody uses it by mistake.
>
>Hm, that would be a different option. But I thought we had the vcl versioning
>for exactly that kind of change, where syntax remains compatible despite
>semantic changes.

I dont know why you would think this is a semantic change ?

By default nothing happens any differently.

If you start using this feature, it has consequences, just like if you start
using esi, gzip or other features we offer.

Would you also bump the VCL version if we added a brotli VFP ?

If we think the risk of unintended consequences from included vcl-library code
is too big, controling this behaviour with a feature-flag makes a lot of sense.

> Though we had agreed on vcl_lookup already, the only regrets I have about the
> current situation is that elevated frustration levels could have been avoided.

No!

I have *only* ever agreed to look at a suggested implementation and its
documentation, and having seen the former has not changed my mind.

If you want vcl_lookup{}, you only chance is to do it by writing
documentation which makes a compelling argument for it carrying its
weight.

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