feat: add body field to filters

[wooorm-arcjet]

related to PRD-8

[trunk-io]

Merging to main in this repository is managed by Trunk.

• To merge this pull request, check the box to the left or comment /trunk merge below.

[arcjet-rei]

Neat! Good job turning this around quickly. I'll need to review arcjet/arcjet#6412 as well, but the other piece of this is figuring out where we want to shim the remaining work of making this available to users into the roadmap. For now, I'll come back to approve this after looking at the monorepo PR.

[qw-in]

Am I understanding correctly that we always read the request body if a filter rule is configured?

[wooorm-arcjet]

Yes, I looked at using the existing lookups (like ip_lookup), but those are global functions.
I do not know of an an alternative way to optionally pass things into, per call

[qw-in]

Is it not feasible to statically analyze the wirefilter body at say startup and determine if the body is needed? I worry this could maybe have a perf impact for folks with existing filters?

[blaine-arcjet]

Is it not feasible to statically analyze the wirefilter body at say startup and determine if the body is needed?

It is not efficient. Optional data is implemented as external functions that are imported. However, that doesn't allow asynchronicity so this will take extra thought.

[arcjet-rei]

The simplest solution that comes to mind (note that I'm not advocating for it, I'm just contributing it for brainstorming purposes) would be to create a new rule type that is the same as a filter rule only it adds reading the body (e.g. FilterWithBody). It's not the most ergonomic solution from a DX perspective, because it requires people to notice that they're adding matching on a body, but if we tailored the error logs with this in mind it wouldn't be too bad.

[blaine-arcjet]

I'm going to convert this to a draft while we consider how to resolve the concerns @qw-in and I have about the performance hit on each filter rule (even without using body)

[wooorm-arcjet]

Yes, it is possible to only read the body if needed, by:

• a) calling into WebAssembly once when filter() is called, analyzing all expressions, this I just implemented
• b) asking users to define this, either with localFilter() or so which is like what @arcjet-rei proposes, or some other flag, which would not be difficult to implement
• c) for the WebAssembly to be able to callback into JavaScript to read the body if needed, which may be difficult to implement.

Although b) would theoretically be fastest (only one call into webassembly and no calls out of it), I think c) is the ideal scenario, and a) may be good enough until c) is feasible.

Real world benchmarks are difficult, because giant bodies will be slow to read and take much more time than calling into/out of WebAssembly, if for example this CVE WAF idea would be automatically applied to every Arcjet user.

If 1 out of 10 filter()s in the wild would use body, then analyzing makes sense. If 9 out of 10 filters() use body, then not analyzing and just reading body makes more sense.

Running the benchmark I commited, the results on my machine are:

bench (simple): `10000` iterations, total time: `3947.35ms`, time per iteration: `0.39ms`
bench (read the body every 10th iteration): `10000` iterations, total time: `4685.44ms`, time per iteration: `0.47ms`
bench (analyze every expression, read the body every 10th time): `10000` iterations, total time: `8884.36ms`, time per iteration: `0.89ms`
bench (always read the body): `10000` iterations, total time: `16073.67ms`, time per iteration: `1.61ms`

• “Simple” is the baseline, the current state. No body support.
• The second is like @arcjet-rei’s idea, b) above. The real performance depends on how slow bodies are and how often body is needed, this case is 1 in 10.
• The third is the current code, a) above. Same real perf notes apply.
• Last would be idea b) if every expression needs the body