Multipart Form Data "RoutingContext::fileUploads"

[jawaff]

Describe the feature

Multipart form data has changed quite a bit with this new strategy. I'm not sure if this is the actual plan going forward, but we're losing what I think is pretty crucial functionality from what I can tell. One of which being that files used to be streamed to disk and then available to be streamed somewhere else from the file. The other is the filename of the file uploaded in the multipart form data, which comes from the content disposition header.

Maybe this already exists through some other form, but I don't see any tests in this repo that upload file, set a nonempty content disposition or use the body handler for limiting file upload size.

Use cases

Streaming files means that there's less risk of out of memory exceptions. Also, the content disposition header is standard and being unable to access its value through some means is weird.

These are probably just not supported yet, but I find it pretty weird how many breaking changes are being introduced. RoutingContext::fileUploads and the RoutingContext body just aren't used anymore from what I can tell. The validated body has to be pulled from the data map now in the context instead.

Contribution

Who should implement this feature ? are you volunteering for implementing this feature or
do you know that is able and willing implement this feature ?

[jawaff]

wrong repo... sorry

[jawaff]

I'm getting lost here. The vertx-web-openapi-router module in vertx-web is technically what I'm integrating with, but it doesn't have a whole lot of anything to it aside from some minimal integration. It depends a lot on this library.

[jawaff]

It looks like the name of the part is pulled from the content disposition header in the MultipartPart class, but there is no retrieval of the filename or any sort of conditional logic based on the content type.

Straight from a test that was working with the previous OpenAPI solution, I've got this header for a "part" of a multipart form data request:

Content-Disposition: form-data; name="file"; filename="testAttachments.txt", Content-Type: application/octet-stream, Content-Transfer-Encoding: binary

This definitely seems to be missing functionality. The MultipartPart file is very basic in its approach compared to what previously existed.

[jnbdz]

This actually covers two distinct gaps, so it might be worth splitting the discussion:

1. filename (and other part metadata) is parsed away

Since the byte-level part parsing landed (#130), MultipartPart already isolates each part's header section — it just only extracts name and Content-Type and drops everything else, including filename. Parsing filename out of Content-Disposition is a small change. The real design question is where to surface it: the analyser's output is the JSON structure that gets schema-validated (part name → value), and the filename is metadata rather than part of the validated body. Two options:

• expose the parsed part metadata (name, content type, filename) through ValidatedRequest, or
• keep vertx-openapi strictly about validation and surface it in vertx-web-openapi-router instead, closer to the old RoutingContext::fileUploads semantics.

2. Streaming / fileUploads() / upload size limits

This one is more fundamental: ValidatableRequest carries the body as a Buffer, so the whole multipart payload is held in memory during validation — the OOM concern is real for large uploads. That can't be fixed inside MultipartFormAnalyser alone; it needs an agreed contract with vertx-web-openapi-router. One possible shape: when an operation's multipart schema marks a part as format: binary, the router lets BodyHandler stream uploads to disk as before (populating fileUploads() and enforcing size limits) and passes only the non-file fields plus the file metadata (filename, content type, size) into validation, instead of buffering file content into the JSON structure. Beyond presence and content-type checks there is not much to validate about binary content anyway.

I'm happy to implement both. (1) is a straightforward PR in this repo once the "where to expose it" question is answered. For (2) I'd like maintainer input first on whether the BodyHandler-delegation approach fits the intended architecture between the two modules, or whether you'd rather see ValidatableRequest learn a notion of externalized/streamed parts.

@pk-work does splitting it this way make sense to you?