Handle an unknown HTTP method instead of raising IllegalArgumentException

[M0nd0R]

An unknown HTTP method reaches HttpMethodInterceptor and produces a 500.

HttpMethod.parse() is valueOf(method.toUpperCase()) with no fallback, and the interceptor calls it with the raw request method for any HttpMethodAware action — before the allow-checks, and with no try/catch:

HttpMethod method = HttpMethod.parse(request.getMethod());

The enum has nine constants, so PROPFIND, MKCOL, REPORT or any invented token raises IllegalArgumentException instead of being treated as "not allowed". When http-method is configured the code already knows how to answer that case — 405 with an Allow header — it just never gets there.

HttpMethod.parseOrNull() returns null for an unrecognised method; the interceptor leaves the method unset and falls through to the existing isAllowed() check. Both parse() and parseOrNull() use toUpperCase(Locale.ROOT) — the bare call is locale-sensitive, and XmlDocConfigurationProvider already uses Locale.ROOT for the same lookup.

Repro: any action with http-method set, request PROPFIND /that-action → 500 before, 405 + Allow after.

Tests: four added to HttpMethodTest. mvn -pl core -Dtest=HttpMethodTest test → BUILD SUCCESS, 6 tests, 0 failures (JDK 21).

Two process notes, so you can redirect me:

• There is no WW-XXXX ticket for this yet, and the contributing guide requires one. Tell me the key to use and I will update the title and commit message to match.
• This is an error-handling bug rather than a vulnerability in the sense of SECURITY.md. If you would rather it went through security@struts.apache.org, close this and I will send it there instead.