[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:

> Do we need a way to fix the hash within vcl_recv?

Strictly speaking no, but wouldn't that just introduce the "leak"
where the freeze isn't called either ?

> Should we bump the vcl version?

Since we are 100% backwards compatible at VCL level, I see no reason.

> Existing VCL could, for example, rely on vcl_hash to be called.

And it will still be called, *precisely* as it has always been,
unless and until people explicitly change their VCL to start calling
hash_data() in vcl_recv{} context.

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.

Dridi Boukelmoune writes:

> So today we have this:
>
> - vcl_recv
> - vcl_hash
> - lookup

Yes, that's what we had before, and that's what we have after my
change too, unless and until people start calling hash_data() in
vcl_recv{}, *nothing has changed*.

Really!  If you dont like this new feature, dont use it.  If you
use it, follow the recipe on the tin:

http://varnish-cache.org/docs/trunk/reference/dp_vcl_recv_hash.html

> I think this is a dead end, like the `new` keyword that can be used
> in a branch,

Are there mistakes in VCL ?

Ohhh God yes!

But never forget that VCL is the foundation of Varnish's success,
fuck too much with it, and you will loose users.

> [...] it would be harder to determine at compile time that
> hash_data wasn't relied on in both vcl_recv and vcl_hash

You seem to have a much higher level of ambition for compile-time checks
than I have ever harboured for VCC ?

If we want to attain _that_ level of ambition, the only realistic way
is to make LLVM a mandatory dependency so we can get hold of it's IR.

Dridi Boukelmoune writes:
> It's not too late to revert.

Nils Goroll writes:
> I fear we would soon regret it if we did not.

Poul-Henning answers:

And I'm 100% fine with that.

But do not make the mistaken assumption that vcl_lookup{} then automatically goes in!

As I said in the original ticket:  To add a new vcl_*{} must clear
a *very* high barrier of additional benefits and vcl_lookup{} is
no where near.

If you want vcl_lookup{}, you have to make a *MUCH* stronger use case
and come up with *MUCH* more interesting things it can be used for.

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