Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Remove support for "request params" from WebFlux [SPR-15508] #20067
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
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
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
Referenced from: commits 1881727
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
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