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

[Nils Goroll]

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

Neither of these stop calling a built-in sub. And exactly that is what I would
call a relevant semantic change.

I agree that we should only use the vcl version if necessary. As you might
remember, there have been a number of proposals for vcl version bumps which I
thought would not qualify.

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

It does - but, again, I would have thought our mechanism for this kind of change
was the vcl version.

Anyway, this is one of two issues currently on the table. The other is the
problem of "fixing" the hash within vcl_recv.


> If you want vcl_lookup{}

I do not think I said I would.

What I said is that I think it is the least worst solution to #3259 currently on
the table.

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/808b06ff/attachment.bin>