fix(pipeline): reject non-HTTP slash arguments - #1389
Conversation
Signed-off-by: Yyunozor <yyunozor@icloud.com>
|
Thanks for opening this — it has been seen, and it is queued. This note is automated, but it is not a brush-off: it exists so you know where your PR stands instead of having to guess from silence. Current review status: working through a backlog. What that means for this PR, concretely:
Things that will genuinely speed it up whenever review does happen:
If this fixes a bug, a reproduction we can run is worth more than a description of the symptom. Thanks for contributing, and sorry in advance for the wait. |
|
Thank you for narrowing the route heuristic to HTTP-shaped slash arguments and for adding focused extraction coverage. This is now routed as a high-priority parsing fix in |
Summary
arg_urlroutesRoot cause
detect_url_in_args()normalized every slash-prefixed call argument andcreated a
Routenode directly. That path bypassed the shared route-literalguard already used by the later route-node pass, so local filesystem paths and
regex operands could become
Routenodes andHTTP_CALLSedges.The change first rejects slash-prefixed raw expressions (string literals and
propagated constants are carried separately), routes the remaining heuristic
through the shared guard, and extends the callee filter to non-HTTP string
consumers such as
replace,match,search,test, andexec.Validation
scripts/test.sh --suites 'infrascan pipeline'— 241 passedsink(/<table/i)andtemplate.replace('/html/g', ...)cli(255 passed, 2 failed) anddaemon_runtime(42 passed, 1 failed)This addresses the
arg_urlregex/path bucket of #598. GraphQL andwhole-config-text classification remain out of scope.