Provide configuration properties for more of Undertow's server options

[melloware]

Currently for Undertow I don't see a way of setting many of the HTTP connector settings such as Max Request Parameters and Max Header size. The only Parameters I see available are here:

https://docs.spring.io/spring-boot/docs/current/reference/html/common-application-properties.html

Many applications have the need to increase the maximum number of request parameters above the defaults set by Undertow.

Property	Description
max-parameters	The maximum number of query or path parameters that are allowed. This limit exists to prevent hash collision based DOS attacks.
max-headers	The maximum number of headers that are allowed. This limit exists to prevent hash collision based DOS attacks.
max-cookies	The maximum number of cookies that are allowed. This limit exists to prevent hash collision based DOS attacks.
allow-encoded-slash	Set this to true if you want the server to decode percent encoded slash characters. This is probably a bad idea, as it can have security implications, due to different servers interpreting the slash differently. Only enable this if you have a legacy application that requires it.
decode-url	If the URL should be decoded. If this is not set to true then percent encoded characters in the URL will be left as is.
url-charset	The charset to decode the URL to.
always-set-keep-alive	If the 'Connection: keep-alive' header should be added to all responses, even if not required by spec.
disallowed-methods	A comma separated list of HTTP methods that are not allowed.  HTTP TRACE is disabled by default.

[wilkinsona]

While we don't offer properties for those, they can be configured programatically using an UndertowBuilderCustomizer added to the Undertow factory and setting the relevant server option on the Builder.

We'll review the settings where we don't have a configuration property and see which of them, if any, we want to add one for.

[melloware]

@wilkinsona Excellent I appreciate the consideration. I would think the 3 "max" parameters would definitely make sense as for the others maybe not so much.

[rhamedy]

Should the team decide to add props then I would be happy to work on unless @melloware wants to do it ☺️

[melloware]

@rhamedy It's all yours!

[wilkinsona]

Thanks for the offer, @rhamedy. We've decided that we'd like to add all of the missing properties. Are you still interested in contributing this change?

[rhamedy]

Yes @wilkinsona, I would love to make my first spring boot contribution. Is there anything I should keep in mind when working on this?

[wilkinsona]

Thanks, @rhamedy. I don't think there are any major gotchas to keep in mind. Not sure if you'll need them, but here are a few pointers for where the changes need to go:

• Fields and accessors should be added to Undertow
• New properties should be applied in UndertowWebServerFactoryCustomizer
• Tests for the new properties should be added to UndertowWebServerFactoryCustomizerTests

Thanks again. If you have any questions, please don't hesitate to ask.

[rhamedy]

@wilkinsona thanks for the pointers.
Before I push my changes up, would be nice to hear your feedback in regards to the following

• io.undertow.UndertowOptions of undertow-core-2.0.19.Final.jar does not have list disallowed-methods as a result cannot map the property in UndertowWebServerFactoryCustomizer. Should we leave it out or there is an alternative way to achieve it?

• In UndertowWebServerFactoryCustomizer I wrote a reusable customizer as follow (instead of writing a private method for each UndertowOption)

private <T> void customizeProperties(ConfigurableUndertowWebServerFactory factory,
	         Option<T> propType, T prop) {
	  factory.addBuilderCustomizers((builder) -> builder.setServerOption(propType, prop));
}

I have reused the above methods for all newly added UndertowOptions.x. Any objections? If none, then I wanted to replace the existing methods with this version.

• Lastly, I wanted to static import all of fields of UndertowOptions as follow

import static io.undertow.UndertowOptions.*;

or

import static io.undertow.UndertowOptions.MAX_PARAMETERS;
and so on ... others used

What's the best practice in this regards? If this is acceptable then I will do the same in the test class and should shorten the lines of code.

[wilkinsona]

disallowed-methods is an interesting one as it's configured differently to the other options. It's implemented using a DisallowedMethodsHandler. I'm not certain that TRACE is disallowed by default in Undertow and suspect that may be a JBoss Wildfly default. @melloware, what's the source of the text in the table in your opening comment?

Any objections? If none, then I wanted to replace the existing methods with this version.

None at all. I like the idea of the customization being reusable.

We don't use * imports in Boot (and Checkstyle will complain if you try to do so). Please follow the style of the current code where UndertowOptions is imported and the constants are referenced as UndertowOptions.MAX_ENTITY_SIZE etc.