Spring-boot: server.max-http-post-size is an Integer

[hadrienk]

The max-http-post-size is an Integer, effectively limiting (in Undertow a least) HTTP entity body to 2GiB.

@ConfigurationProperties(prefix = "server", ignoreUnknownFields = true)
public class ServerProperties
        implements EmbeddedServletContainerCustomizer, EnvironmentAware, Ordered {

    /**
     * Maximum size in bytes of the HTTP post content.
     */
    private int maxHttpPostSize = 0; // bytes

    private void customizeMaxHttpPostSize(
            UndertowEmbeddedServletContainerFactory factory,
            final int maxHttpPostSize) {
        factory.addBuilderCustomizers(new UndertowBuilderCustomizer() {
            @Override
            public void customize(Builder builder) {
                builder.setServerOption(UndertowOptions.MAX_ENTITY_SIZE,
                        (long) maxHttpPostSize);
            }
        });
    }
}

package io.undertow;

public class UndertowOptions {

   /**
     * The default maximum size of the HTTP entity body.
     */
    public static final Option<Long> MAX_ENTITY_SIZE = Option.simple(UndertowOptions.class, "MAX_ENTITY_SIZE", Long.class);
}

[wilkinsona]

A couple of things to consider here:

• Both Tomcat and Jetty use an int for the max size
• Changing to a long will be binary incompatible.

Perhaps we should only consider changing this in 1.5? In the meantime, anyone who needs a larger size with Undertow can use their own customiser to configure it

[hadrienk]

Is maxHttpPostSize having the same meaning (entity size) in Tomcat and Jetty?

How about using -1 and exposing the UndertowOptions.MAX_ENTITY_SIZE options inside the ServerProperties.Undertow inner class?

[wilkinsona]

Is maxHttpPostSize having the same meaning (entity size) in Tomcat and Jetty?

On closer inspection; not really, no. In Jetty it only appears to affect PUT or POST requests with a content type of x-www-form-urlencoded. In Tomcat it only appears to affect POST requests with a content type of multipart/form-data or application/x-www-form-urlencoded.

Given the differences between the three containers, I wonder if we should deprecate the current properties and provide container-specific variants that can more accurately describe the behaviour?