Add server.request.body.filenames AppSec address for Vert.x 3.4, 4.0 and 5.0

[jandro996]

What Does This Do

Instruments RoutingContextImpl.fileUploads() in the Vert.x Web 3.4, 4.0 and 5.0 modules to fire the server.request.body.filenames AppSec IG event, enabling WAF-level detection and blocking on uploaded file names.

New callsites

• vertx-web-3.4: new RoutingContextFilenamesAdvice (returns Set<FileUpload>), wired in RoutingContextImplInstrumentation
• vertx-web-4.0: new RoutingContextFilenamesAdvice (returns Collection<FileUpload> to cover both Set in 4.0.x and List in 4.5.x+), wired in RoutingContextImplInstrumentation
• vertx-web-5.0: new RoutingContextFilenamesAdvice (returns List<FileUpload>) + new RoutingContextImplInstrumentation

All three advice classes use FileUpload.class as the CallDepthThreadLocalMap key (public interface, avoids IllegalAccessError when ByteBuddy inlines the advice into RoutingContextImpl).

Test server fixes

All four VertxTestServer variants (3.4, 4.0/test, 4.0/latestDep, 5.0) had a broken BODY_MULTIPART handler that used setExpectMultipart(true) + an async endHandler, bypassing BodyHandler. This prevented fileUploads() from ever being populated. Replaced with:

1. BodyHandler.create() registered as a prior handler on the same route
2. A synchronous handler that calls ctx.fileUploads() before convertFormAttributes(ctx)

testBodyMultipart() continues to pass because BodyHandler also populates formAttributes().

Added .gitignore files in each module root to suppress the file-uploads/ temporary directories that BodyHandler.create() creates on disk during test execution.

NettyMultipartHelper fix

Vert.x's internal NettyFileUpload throws UnsupportedOperationException from getHttpDataType(). Added a try-catch to skip such items silently - they are handled by Vert.x's own instrumentation. Without the fix, the exception was swallowed by ByteBuddy's suppress = Throwable.class but incremented INSTRUMENTATION_ERROR_COUNT, causing the Vert.x 5.0 integration tests to fail with "1 instrumentation error". Coverage is provided by the Vert.x 5.0 forked tests in this PR.

Motivation

solves APPSEC-61873 (partial - Vert.x coverage)

Additional Notes

Double-instrumentation in 5.0 tests: the vertx-web-5.0 test module includes vertx-web-4.0 as testImplementation, so both RoutingContextImplInstrumentation classes are applied in the same test run. Using Collection<FileUpload> in the 4.0 advice (instead of Set<FileUpload>) was necessary to avoid a ByteBuddy type-mismatch error when Vert.x 4.5.x+ changed the return type of fileUploads() from Set to List. Once the type error was gone, both advices coexist correctly via the shared CallDepthThreadLocalMap key.

Static reflection pattern: FILE_UPLOAD_REF is defined as a static final Reference in each RoutingContextImplInstrumentation (not a VertxVersionMatcher constant) because it is only needed by that single class. The 5.0 instrumentation uses HTTP_HEADERS_INTERNAL (io.vertx.core.internal.http.HttpHeadersInternal, absent in 4.x) as the version discriminator to prevent the 5.0 advice from applying to Vert.x 4.x classloaders.

JVM constraint: vertx-web-3.4 and vertx-web-4.0 default test set maxJavaVersion = VERSION_15; tests must be run with -PtestJvm=11 via forkedTest (not test).

Contributor Checklist

• Format the title according to the contribution guidelines
• Assign the type: and (comp: or inst:) labels in addition to any other useful labels
• Avoid using close, fix, or any linking keywords when referencing an issue
  Use solves instead, and assign the PR milestone to the issue
• Update the CODEOWNERS file on source file addition, migration, or deletion
• Update public documentation with any new configuration flags or behaviors

Jira ticket: APPSEC-61873

Note: Once your PR is ready to merge, add it to the merge queue by commenting /merge. /merge -c cancels the queue request. /merge -f --reason "reason" skips all merge queue checks; please use this judiciously, as some checks do not run at the PR-level. For more information, see this doc.

[jandro996]

@codex review

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Delightful!

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[dd-octo-sts]

Hi! 👋 Thanks for your pull request! 🎉

To help us review it, please make sure to:

• Add at least one type, and one component or instrumentation label to the pull request

If you need help, please check our contributing guidelines.