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

[Nils Goroll]

Hi,

thank you for the quick answer

On 16/02/2021 08:30, Poul-Henning Kamp wrote:
> 
>> 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 ?

Having reflected on it, I am not sure if the "hash_fix()" within vcl_recv {}
would be a good solution. I had mentioned the idea in order to salvage the
hash_data() change, but I agree with you that it could easily be forgotten and
thus would be of limited use.

I think Diri has explained nicely how the "demarcation lines" between the fsm
states clearly are a superior concept, and with the hash_data change we would
have, to some degree, given up on it.

So please, for now, please take my question only as indication of an issue we
need to address

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

The problem I see here is with the real-world practice of VCL code reuse, where
people just do not consider that, once they use hash_data(), they would need to
review all their "library VCL".

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

> 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 I understand your commits.

But my concern is that, for the "VCL library" case, this would not be practical.

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

phk, I am 100% with you, and this thread is _exactly_ about this point. I think
the hash_data change falls into the f*ckup category.

> (revert)
> And I'm 100% fine with that.

OK, I think we should do that then and take the time to find whatever we think
is the best solution.

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

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.

That is to say, I do not question your veto right, no matter how late the hour,
and I do not think anyone else does. The situation is unfortunate on the
emotional side, but we should all be allowed to change our minds.

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

In my opinion, vcl_lookup{} is the best proposal for the respective use case I
have seen so far. That does not mean it needs to be the best one, I have just
not seen a better one yet.

In particular, I think the hash_data() change also has unresolved issues.

Let's take the time to find the best possible solution and agree on it.

Nils

-- 

** * * UPLEX - Nils Goroll Systemoptimierung

Scheffelstraße 32
22301 Hamburg

tel +49 40 28805731
mob +49 170 2723133
fax +49 40 42949753

xmpp://slink@jabber.int.uplex.de/

http://uplex.de/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-commit/attachments/20210216/0a32d025/attachment.bin>