[master] eb85bf87c vrt_filter: Minor polish

[Nils Goroll]

On 13.02.25 12:34, Dridi Boukelmoune wrote:
> 
> commit eb85bf87cae0b9feca74a20a1cee2b54a2b06d57
> Author: Dridi Boukelmoune <dridi.boukelmoune at gmail.com>
> Date:   Thu Feb 13 12:22:39 2025 +0100
> 
>      vrt_filter: Minor polish
>      
>      I'm not convinced by req_filter_can(). Filters have no effect on a
>      bereq, beresp or resp without a body, why should it be different for
>      req? We should be consistent here.

I would hope that your question was answered by the vcl_var.rst addition from 
00b190a0aed482a638fdb9f1207598cca3db6c27:

The req body (conversely to others) is one where VCL has control over when it 
gets processed by means of std.cache_req_body(): Filters act on the received 
body when that function is called, so confusion could be caused if people expect 
filters to have an effect when set/changed after the req.body is already cached.

To implement trailer support, I think we would need generic vcl "send/receive 
the body _now_" control, and this mechanism would get generalized.

> -	(void)bo;
> +	CHECK_OBJ_NOTNULL(bo, BUSYOBJ_MAGIC);

I am not against, but why null/magic check an unused value?

Otherwise thank you for the cstyle touchups.

Nils

-- 

Nils Goroll (he/him)

** * * 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: OpenPGP_0x1DCD8F57A3868BD7.asc
Type: application/pgp-keys
Size: 3943 bytes
Desc: OpenPGP public key
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-commit/attachments/20250213/43d19548/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-commit/attachments/20250213/43d19548/attachment-0003.bin>