Jetty maxFormContentSizeJetty not working? Here’s the fix

People are generally prescribing something like this to configure maxFormContentSize for jetty in the jetty.xml:

<Configure id="Server" class="org.eclipse.jetty.server.Server">
	...
    <Call name="setAttribute">
        <Arg>org.eclipse.jetty.server.Request.maxFormContentSize</Arg>
        <Arg>10000000</Arg>
    </Call>
</Configure>

In my experience, in 2024 with a recent version of jetty (9.4.53), this isn’t working inside apache’s karaf or in embedded mode within maven, and may not be working in other containers as well.

Fix #1: set the jetty server attribute as a system property

The trick to fix this is to replace the call xml block to set a system property instead:

Old:

<Call name="setAttribute">

New:

<Call class="java.lang.System" name="setProperty">

Fix #2: ensure you’re in the right jetty file

Be careful to ensure you’re putting the maxFormContentSize system property in the right file. Your project could contain various files that define the server, those files will start with this:

<Configure id="Server" class="org.eclipse.jetty.server.Server">

It’s possible to do all sorts of overriding insanity. For example you can break http-specific config out to a jetty-http.xml file that’s different than the jetty.xml or a jetty-https.xml file. Maybe someone on your team has copy/pasted the configuration to one of those other files.

Fix #3: Jetty’s maxFormContentSize doesn’t work in embedded Maven plugin

The fix listed above for the jetty.xml doesn’t seem to take effect in the jetty-maven-plugin, instead, in that case, define the system property like so in your pom.xml:

<plugin>
	<groupId>org.eclipse.jetty</groupId>
	<artifactId>jetty-maven-plugin</artifactId>
	<version>9.4.53.v20231009</version>
	<configuration>
		<jettyXml>src/main/resources/jetty.xml</jettyXml>
		<webApp>
			<contextPath>/myApp</contextPath>
		</webApp>
		<webAppSourceDirectory>${project.build.outputDirectory}</webAppSourceDirectory>
		<systemProperties>
			<systemProperty>
				<name>org.eclipse.jetty.server.Request.maxFormContentSize</name>
				<value>1073741824</value>
			</systemProperty>
	</configuration>

	... dependencies and so on ...
	
</plugin>

Fix #4 Debug It Yourself

It took me a fair bit of debugging and hunting around to paste this together, here are some pointers to that end.

The “org.eclipse.jetty.server.Request.maxFormContentSize” configuration key sure seems like a spring or some other bean-friendly configuration way to set a property called maxFormContentSize on a class called org.eclipse.jetty.server.Request, and maybe in the past that was true, or maybe I’m doing something wrong, but it doesn’t seem to work, so here’s some pointers…

In Jetty’s org.eclipse.jetty.server.Request class you’ll see this:

public void extractFormParameters(MultiMap<String> params) {
    int maxFormContentSize = ContextHandler.DEFAULT_MAX_FORM_CONTENT_SIZE;
    int maxFormKeys = ContextHandler.DEFAULT_MAX_FORM_KEYS;

    if (_context != null) {
        ContextHandler contextHandler = _context.getContextHandler();
        maxFormContentSize = contextHandler.getMaxFormContentSize();
        maxFormKeys = contextHandler.getMaxFormKeys();
    } else {
        maxFormContentSize = lookupServerAttribute(ContextHandler.MAX_FORM_CONTENT_SIZE_KEY, maxFormContentSize);
        maxFormKeys = lookupServerAttribute(ContextHandler.MAX_FORM_KEYS_KEY, maxFormKeys);
    }

    ...
}

In my case, the content size was coming from the contextHandler so it never calls the else-block’s ‘lookupServerAttribute’ that presumably works with the original prescriped ‘call setAttribute’ jetty xml configuration.

So, let’s dig deeper, how’s this ContextHandler get the maxFormContentSize?

Toward the top of org.eclipse.jetty.server.handler.ContextHandler, we see this:

private int _maxFormContentSize = Integer.getInteger(MAX_FORM_CONTENT_SIZE_KEY, DEFAULT_MAX_FORM_CONTENT_SIZE);

This was news to me, but you can apparently get a Integer java system property using Integer.getInteger() there, so that’s cool. Internally Integer.getInteger is a wrapper around System.getProperty() (JDK 11 code shown..):

public static Integer getInteger(String nm, Integer val) {
    String v = null;
    try {
        v = System.getProperty(nm);
    } catch (IllegalArgumentException | NullPointerException e) {
    }
    if (v != null) {
        try {
            return Integer.decode(v);
        } catch (NumberFormatException e) {
        }
    }
    return val;
}

So, if you want to precisely debug when ContextHandler is grabbing this system property, you can set a breakpoint there in Integer.getInteger() and that’ll be called not-too-often on boot, or better yet, set a conditional breakpoint in System.getProperty():

public static String getProperty(String key) {
    checkKey(key);
    SecurityManager sm = getSecurityManager();
    if (sm != null) {
        sm.checkPropertyAccess(key);
    }

    return props.getProperty(key);
}

Make your conditional breakpoint break when key is “org.eclipse.jetty.server.Request.maxFormContentSize”, then, assuming you’re in eclipse, do yourself a favor and add a watch expression of props.keySet().toString() and look at the various sys property keys that way.

One more thing, you are going to want the JDK to wait on your debugger attaching before it starts booting up jetty, so start your java process in a waiting mode using the suspend=y flag, an example from my script that I use to run jetty in maven:

if [ "debug" = "${1}" ]; then
	DEBUG_OPTS=-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=6006
elif [ "debug+wait" = "${1}" ]; then
	# note the difference here compared to above is suspend=y
	DEBUG_OPTS=-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=6006
fi

export MAVEN_OPTS="-Xdebug -Xnoagent -Djava.compiler=NONE ${DEBUG_OPTS}"

Hope this helps.