`PartEvent` API should support limiting the number of file parts

[kzander91]

With the "old" WebFlux multipart functionality, we could limit the number of parts with org.springframework.http.codec.multipart.DefaultPartHttpMessageReader#maxParts, and the maximum part size with a combination of org.springframework.http.codec.multipart.DefaultPartHttpMessageReader#maxInMemorySize and org.springframework.http.codec.multipart.DefaultPartHttpMessageReader#maxDiskUsagePerPart.

But org.springframework.http.codec.multipart.PartEventHttpMessageReader does not offer such a configuration. It does have maxInMemorySize, but that can only be used to limit the size of form parts and has no effect on file parts.

Is there a particular reason for not offering that configuration? Is there another recommended way of implementing these limits myself when using PartEvent?

[poutsma]

We can introduce the maxParts property in the PartEventHttpMessageReader, and will do so for 6.1.

Because the PartEventHttpMessageReader never stores the part contents on disk, it does not make sense to introduce the maxDiskUsagePerPart. The maxInMemorySize property also does not apply, because PartEvent do not contain collated data (unlike Part objects), i.e. the maximum size a PartEvent can have is equal to the HTTP server buffer size. So unless you use buffer, or similar methods, to collate the part events into a list, you should be fine.

[kzander91]

I have a business requirement that files should be less than 5MB in size and I was using maxDiskUsagePerPart and maxInMemorySize to enforce that. This is now no longer possible...

[poutsma]

I'll see if I can add a maxPartSize property as well.

[kzander91]

@poutsma Shouldn't this line

spring-framework/spring-web/src/main/java/org/springframework/http/codec/multipart/PartEventHttpMessageReader.java

Line 194 in 66aac7e

int maxSize = (int) Math.min(this.maxInMemorySize, this.maxPartSize);

take into account that maxPartSize is -1 by default? Otherwise, not setting the new maxPartSize property will effectively disable the existing maxInMemorySize of 256k...

Maybe a better approach would be to rename the properties to something like maxFormPartSize and maxFilePartSize and then only apply them when decoding form parts and file parts respectively...

What do you think?

Context: I'm currently preparing a PR to add auto-configuration for these new properties to Spring Boot and am having trouble coming up with a concise description of what these are actually controlling.

[poutsma]

@poutsma Shouldn't this line

spring-framework/spring-web/src/main/java/org/springframework/http/codec/multipart/PartEventHttpMessageReader.java

Line 194 in 66aac7e

int maxSize = (int) Math.min(this.maxInMemorySize, this.maxPartSize);

take into account that maxPartSize is -1 by default? Otherwise, not setting the new maxPartSize property effectively disables the existing maxInMemorySize of 256k...

Good point, I will fix that.

Maybe a better approach would be to rename the properties to something like maxFormPartSize and maxFilePartSize and then only apply them when decoding form parts and file parts respectively...

Renaming the properties would break backward compatibility, so that's not really an option at this point. Moreover, this change would ignore the fact that maxInMemorySize is also used to determine the threshold when switching from in-memory to file storage in the DefaultPartHttpMessageReader, and I'd like to keep the properties similar to facilitate switching between the two.