Re: [nft PATCH v2] parser_json: support handle for rule positioning in JSON add rule

[Phil Sutter <phil@nwl.cc>]

Hi,

On Sun, Nov 02, 2025 at 01:41:48PM +0100, Florian Westphal wrote:
> Alexandre Knecht <knecht.alexandre@gmail.com> wrote:
>  Export/import scenario (handles are metadata):
> >   {"add": {"rule": {"family": "inet", "table": "test", "chain": "c",
> >                     "handle": 4, "expr": [...]}}}
> >   → Handle 4 is ignored, rule appended
> > 
> > Explicit positioning:
> >   {"add": {"rule": {"family": "inet", "table": "test", "chain": "c",
> >                     "position": 2, "expr": [...]}}}
> >   → Rule added after handle 2
> > 
> > What do you think about this approach? I can implement it if you agree it's
> > the right direction.
> 
> I think its a sensible strategy, yes.
> 
> Reactivating the handle is a no-go as it will break existing cases.

Though libnftables-json.5 has this description of rule's "handle"
property:

"The rule’s handle. In delete/replace commands, it serves as an
identifier of the rule to delete/replace. In add/insert commands, it
serves as an identifier of an existing rule to append/prepend the rule
to."

So one might declare lack of handle support in "add" commands a bug and
the use-cases depending on it as broken.

We must not stop ignoring handles in implicit add commands as that
breaks 'nft -j list ruleset | nft -j -f -' but we can distinguish
those.

> Could you also add a test case that validates the various relative
> positioning outcomes?
> 
> i.e. given:
> 
> rule handle 1
> rule handle 2
> rule handle 3
> 
> - check that positinging at 1 results in
> rule 1
> rule N
> rule 2
> rule 3
> 
> - check that positining at rule 1 results in
> 
> rule 1
> rule N2
> rule N
> rule 2
> rule 3
> 
> - check that positinging at rule 1 will fail
> in case that rule was already deleted.
> 
> - check that positinging at rule 2 will insert
> after handle 2 and not N2.

I'd suggest extending testcases/rule_management/0001addinsertposition_0
in tests/shell to cover the missing parts above and create a copy for
JSON syntax.

> My only question is how "Position" is treated with insert (instead of
> add).
> 
> It should NOT be ignored, it should either be rejected outright (and
> everywhere its not expected) or it should have different meaning, ie.
> prepend (insert occurs before the given handle).

With insert command, handle property is recognized and behaves identical
to standard syntax. In general, I think JSON syntax parser should
deviate as little as necessary from standard syntax one. Same name but
different function will likely confuse users. Although not documented
anymore, standard syntax still accepts "position" and treats it as
synonym to "handle".

So maybe just do this (untested):

--- a/src/parser_json.c
+++ b/src/parser_json.c
@@ -4045,7 +4045,8 @@ static struct cmd *json_parse_cmd_replace(struct json_ctx *ctx,
                return NULL;
        }
 
-       if ((op == CMD_INSERT || op == CMD_ADD) && h.handle.id) {
+       if (h.handle.id &&
+           (op == CMD_INSERT || op == CMD_ADD || op == CMD_CREATE)) {
                h.position.id = h.handle.id;
                h.handle.id = 0;
        }
@@ -4328,9 +4329,9 @@ static struct cmd *json_parse_cmd(struct json_ctx *ctx, json_t *root)
                enum cmd_ops op;
                struct cmd *(*cb)(struct json_ctx *ctx, json_t *, enum cmd_ops);
        } parse_cb_table[] = {
-               { "add", CMD_ADD, json_parse_cmd_add },
+               { "add", CMD_ADD, json_parse_cmd_replace },
                { "replace", CMD_REPLACE, json_parse_cmd_replace },
-               { "create", CMD_CREATE, json_parse_cmd_add },
+               { "create", CMD_CREATE, json_parse_cmd_replace },
                { "insert", CMD_INSERT, json_parse_cmd_replace },
                { "delete", CMD_DELETE, json_parse_cmd_add },
                { "list", CMD_LIST, json_parse_cmd_list },

Cheers, Phil