Support for limits on input stream processing in WebFlux codecs #23884
Assignees
Labels
in: web
Issues in web modules (web, webmvc, webflux, websocket)
status: backported
An issue that has been backported to maintenance branches
type: enhancement
A general enhancement
Milestone
Comments
rstoyanchev
added
in: web
spring-projects-issues
added
status: backported
rstoyanchev
added a commit
that referenced
this issue
Oct 29, 2019
- Add maxInMemorySize property to Decoder and HttpMessageReader implementations that aggregate input to trigger DataBufferLimitException when reached. - For codecs that call DataBufferUtils#join, there is now an overloaded variant with a maxInMemorySize extra argument. Internally, a custom LimitedDataBufferList is used to count and enforce the limit. - Jackson2Tokenizer and XmlEventDecoder support those limits per streamed JSON object. See gh-23884
rstoyanchev
pushed a commit
that referenced
this issue
Oct 29, 2019
rstoyanchev
added a commit
that referenced
this issue
Oct 29, 2019
rstoyanchev
added a commit
that referenced
this issue
Oct 29, 2019
- Add maxInMemorySize property to Decoder and HttpMessageReader implementations that aggregate input to trigger DataBufferLimitException when reached. - For codecs that call DataBufferUtils#join, there is now an overloaded variant with a maxInMemorySize extra argument. Internally, a custom LimitedDataBufferList is used to count and enforce the limit. - Jackson2Tokenizer and XmlEventDecoder support those limits per streamed JSON object. - Configurable limits for multipart requests with Synchronoss NIO. - Centralized maxInMemorySize exposed via CodecConfigurer along with ability to plug in an instance of MultipartHttpMessageWrite. Closes gh-23884
|
For an overview see "Limits" section in the reference documentation. |
|
I know this issue was closed in October, but I'm curious @rstoyanchev if you could explain what the downside of not having a limit is? In other words prior to implementing the limit, what could go wrong if the size was very large and how would that manifest; such that adding a limit by default is an effective protection? |
|
@scottjohnson there is some explanation in the docs. It's about making it easy for applications to declare limits on input buffering. In the absence of such limits the application can run out of memory. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
While a proxy, or the underlying server, or a
WebFiltercan be used to enforce general limits on the size of server request input, it would be helpful forDecoderandHttpMessageReaderimplementations to expose configurable limits too, because codecs in WebFlux can parse asynchronously and pass one object one at a time to the application, as a stream. That means the overall request input stream may be infinite, and it's the input per streamed object that should be limited.The text was updated successfully, but these errors were encountered: