Different actuator port changes HTTP status codes on errors

[sapirozz]

Using spring-boot-actuator 1.5.4 and Spring boot admin 1.5.3 we cannot see the "Environment Manager" tab for our client applications.

The problem is caused by the wrong error code returned by the refresh endpoint with HTTP verb HEAD.
The spring admin expects 405 (Method not allowed) but the actuator endpoint returns error 500.

This problem is related to the definition of an alternative port for the management, in that case the Dispatch Servlet has only one Exception handler and not the standard two because it is configured by the EndpointWebMvcChildContextConfiguration class.

If we use the server port for the management, without an alternative port, the request on refresh endpoint with HEAD verb returns the right code 405.

For us the alternative port is necessary and we didn't find a workaround to solve the problem.

[philwebb]

Can you share a sample application that shows the problem?

[sapirozz]

Here you can download the sample application testapp.zip.

The test app is a very simple application that exposes the actuator endpoints.
If you run the application as it is, the management port is different from the server port and if you perform an HEAD request on the endpoint http://localhost:8889/management/refresh you receive an internal server error (500 error code).

If you edit the application.yml removing the management.port and management.context-path properties and then execute the HEAD request on the endpoint http://localhost:8888/refresh you receive the Method not Allowed error (405 error code) as expected.

This different behaviour represents a problem into the integration with the Spring boot admin application.

The app has the same behaviour if you don't specify the version 1.5.7 of the actuator library, using the one imported with the dependencies management.

[mbhave]

When the DispatcherServlet tries to resolve the exception, it uses the CompositeHandlerExceptionResolver which returns an empty list of resolvers.

[pitinga]

Hello @mbhave ...

Any chance to resolve this bug in 1.5.x family?