By default StrictHttpFirewall is configured to allow methods: DELETE, GET, HEAD, OPTIONS, PATCH, POST, PUT. If I issue TRACE method call, RequestRejectedException will be correctly thrown. If I use GenericFilterBean to catch it

    try {
        chain.doFilter(req, res);
    } catch (RequestRejectedException e) {…}

it will not be catch here, and 405 is issues. All fine, I want this.

But I also want to ban: HEAD, OPTIONS, PATCH globally. So i define StrictHttpFirewall bean myself:

    @Bean
    HttpFirewall httpFirewall() {
        StrictHttpFirewall result = new StrictHttpFirewall();
        List<String> allowedHttpMethods = Stream.of(HttpMethod.DELETE, HttpMethod.GET, HttpMethod.POST, HttpMethod.PUT)
                .map(Enum::name)
                .toList();
        result.setAllowedHttpMethods(allowedHttpMethods);
        return result;
    }

If I issue say OPTIONS method, it is catched by this filter.

Is there some other place where I need to somehow need to configure HEAD, OPTIONS, PATCH methods? Why I’m asking: I do have this filter to return 400, because StrictHttpFirewall typically throws RequestRejectedException in case of some fishy request. But when client uses wrong method altogether, I’d like to correctly return 405 and to do that I have (IIUC) no other option than parse exception message of RequestRejectedException, which is not ideal, and it suggests that I’m doing something wrong.