Remove support for "request params" from WebFlux [SPR-15508]

[spring-projects-issues]

Rossen Stoyanchev opened SPR-15508 and commented

In the Servlet API "request params" provide Map-like access to both URI query params and form data (parsed from the request body). The concept fits well in the Servlet API where "request params" are accessed in a blocking fashion whenever needed. It does not however fit with use of the Servlet 3.1 non-blocking I/O API which is mutually exclusive with any calls to get "request params" since those may block.

In M3 #19567 introduced support for Servlet API style "request params" in WebFlux by parsing form data eagerly (without blocking) and then caching it. This was a reasonable trade-off for simple forms that made it feasible to support the concept of "request params".

Recently #19114 introduced support for multipart form data. A multipart request may represent a browser form with a file input field, or it be a non-browser client sending a request with potentially large parts of data of any media type. Support for "request params" is now a challenge. While eager parsing + caching multipart form data may be okay for browser forms (in combination with a max file upload limit) it precludes support for streaming large multiparts sequentially, something that is a natural fit for WebFlux, e.g. a Flux<Part> controller method argument.

This ticket is to remove the concept of "request params" from WebFlux in favor of the more explicit, existing support for access to query params vs form data. We can continue to support data binding of both URI query params and form data (including multipart data) to a command object (via @ModelAttribute). In WebFlux however @RequestParam or @RequestMapping(params="...") would have to refer to URI query params only. This trade-off seems a better fit for WebFlux.

In short the concept of a single bucket (Map) for something so disparate as simple URI query params on one end and very large parts in a multipart form data request on the other is just not feasible while also providing support for on-demand, non-blocking parsing of large content.

---

Affects: 5.0 M5

Issue Links:

• Reactive multipart request support [SPR-14546] #19114 Reactive multipart request support
• Support for "request parameters" (query string + form data) in ServerWebExchange [SPR-15000] #19567 Support for "request parameters" (query string + form data) in ServerWebExchange
• Support for form data via @RequestParam on WebFlux [SPR-16190] #20738 Support for form data via @RequestParam on WebFlux

Referenced from: commits 1881727

[spring-projects-issues]

Rossen Stoyanchev commented

Daniel Fernández, what this means for the use case from #19567 is you cannot map to two different @RequestMapping methods based on which button was pressed.

[spring-projects-issues]

Daniel Fernández commented

Thanks Rossen, understood. I'll take this into account and modify my examples then.

So the expected way to access form data will now be either using ServerWebExchange#getFormData() from the controller code, or of course binding form data to a form-backing bean, correct?

[spring-projects-issues]

Rossen Stoyanchev commented

Yes you can bind form data (including multipart form data) to a form-backing bean. Or at a lower level, and outside a controller, you can use ServerWebExchange#getFormData() and ServerWebExchange#getMultipartData() both of which are safe to call more than once.