hrw4u: Fix u4wrh set-config emitting 3-arg form with HRW type hint

[Clendenin]

Summary

Some legacy header_rewrite configs spell set-config with an explicit HRW type
token (INT, STRING, FLOAT) between name and value. The native ATS parser
has no concept of that token, and HRW4U set-config takes exactly two
arguments. When u4wrh encounters the three-argument form, drop the type token
so the emitted HRW4U call is set-config(name, value).

Adds INT, STRING, and FLOAT reverse fixtures to guard each branch of the HRW
type-hint strip.

[ezelkow1]

[approve ci osx]

[Copilot]

Pull request overview

Fixes u4wrh (header_rewrite → hrw4u reverse compiler) to handle the legacy 3-argument form of set-config that includes an explicit HRW type token (INT, STRING, FLOAT). The native ATS parser/Prism set-config takes only (name, value), so the type token is now stripped during reverse compilation.

Changes:

• In _handle_statement_function, when emitting set-config with 3 args and the middle arg is INT/STRING/FLOAT, drop it and emit a 2-arg call.
• Added three reverse-only fixtures (int/string/float) under tests/data/ops/ covering each branch.
• Listed the new fixtures in exceptions.txt as u4wrh-only (forward never emits the type token).

Reviewed changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
tools/hrw4u/src/hrw_symbols.py	Strip HRW type hint from 3-arg set-config during reverse emission.
tools/hrw4u/tests/data/ops/exceptions.txt	Mark new set-config type-hint fixtures as reverse-only.
tools/hrw4u/tests/data/ops/set-conf-type-int.{input,output}.txt	Reverse fixture covering INT type hint.
tools/hrw4u/tests/data/ops/set-conf-type-string.{input,output}.txt	Reverse fixture covering STRING type hint.
tools/hrw4u/tests/data/ops/set-conf-type-float.{input,output}.txt	Reverse fixture covering FLOAT type hint.

[zwoop]

Hmmm, so this feels like a bandaid on a broken behavior/use of header_rewrite. It feels to me that "fixing" u4wrh to accept this broken input is not making it better, meaning it'd be better to let it give an error such that the source of this can be fixed.

Also, we may want to consider trying to fix the header_rewrite parser to make this an error on config load/reload. It clearly does not behave as you expect.

So my preference here would be to make this input to u4wrh an error, rather than handling it.

@mlibbey Wdyt ?

[mlibbey]

Agree with zwoop. I think the bug here is that when u4wrh runs on

cond %{REMAP_PSEUDO_HOOK} [AND]
cond %{CLIENT-HEADER:X-Thisdoesntcache} ="" [NOT]
  set-config proxy.config.http.cache.http INT 0

it yields the invalid

REMAP {
    if inbound.req.X-Thisdoesntcache {
        set-config("proxy.config.http.cache.http", "INT", 0);
    }
}

if you do the double conversion, hrw4u correctly errors:

<stdin>:3:8: error: Invalid number of arguments (expected 2, got 3)
   3 |         set-config("proxy.config.http.cache.http", "INT", 0);
     |         ^

Also interesting adding the [L] after set-config and giving to u4wrh...

cond %{REMAP_PSEUDO_HOOK} [AND]
cond %{CLIENT-HEADER:X-Thisdoesntcache} ="" [NOT]
  set-config proxy.config.http.cache.http 0 [L]

does not yield a break;

[zwoop]

Lets address these concerns.