Expose the decoder via HttpRequest API

[Praneethvarma]

trafficstars

Describe the feature

Currently, HttpServerRequest provides setExpectMultipart(boolean) to allow for application developers to configure the request to be parsed using a multipart parser. However, this is currently tied to a specific decoder configuration[1][2]. The decoder itself is configurable via the io.netty.handler.codec.http.multipart.HttpDataFactory.

Proposal : Rather than tying the decoder to a certain implementation, I propose that we should expose the ability to set a custom decoder to parse the body.

[1] HTTP1.1 - https://github.com/eclipse-vertx/vert.x/blob/3.9.0/src/main/java/io/vertx/core/http/impl/HttpServerRequestImpl.java#L442 [2] HTTP2 - https://github.com/eclipse-vertx/vert.x/blob/3.9.0/src/main/java/io/vertx/core/http/impl/Http2ServerRequestImpl.java#L417

Use cases

Allows the application developer to plugin application logic into the parsing steps exposed by the io.netty.handler.codec.http.multipart.HttpPostRequestDecoder (using a custom io.netty.handler.codec.http.multipart.HttpDataFactory) or even supply a custom io.netty.handler.codec.http.multipart.InterfaceHttpPostRequestDecoder.

1. I have seen a use case for this where my application logic requires reading the parts that are read so far. I could hook into the parsing logic to collect this information as the parts are read. This could allow for validation throughout the parsing process rather than doing it at the end. Also, allows for using the data/parts received so far to parse the data/parts that follow.
2. Currently, part of multipart processing logic is exposed via the upload handler (in HttpServerRequest). This update would allow more freedom to parse the non file parts as well.
3. One other situation I ran into is where some of my file uploads were coming in with an unexpected charset encoding in the part's Content-Type header. The default factory would fail processing such attributes (In this case, it was a bad charset value which the application does not care about). So, ability to configure the decoder with a custom HttpDataFactory could allow bypass such scenarios in an application friendly way.

Contribution

If we get a consensus here, I can make the required changes.

[vietj]

@praneethvarma yes we could have this done with HttpServerRequestInternal is that's still relevant to you