[Regression] 404 without ACCEPT request header results in a 406 in Spring Framework 5.1.6

[mixcloud-downloader]

Affects: 5.1.6

Since the Upgrade from Spring-Boot-2.1.3.RELEASE to Spring-Boot-2.1.4.RELEASE, any error (e.g. a 404 or an 500) an expected 404 without an ACCEPT request header result in a 406 response and this message in the logs:

DefaultHandlerExceptionResolver : Resolved [org.springframework.web.HttpMediaTypeNotAcceptableException: Could not find acceptable representation]

This regression happens only when setting the default content type to TEXT_HTML:

@Configuration
class DefaultContentTypeConfiguration implements WebMvcConfigurer {

	@Override
	public void configureContentNegotiation(ContentNegotiationConfigurer configurer) {
		configurer.defaultContentType(TEXT_HTML);
	}
}

See spring-attic/spring-framework-issues#191 for an example.

On a site note: This is the second bug in a very short time (the other was #22851) which goes unnoticed with Spring's classic MockMVC testing approach. It makes me thing that using MockMVC is not a too good idea any more.

[rstoyanchev]

This appears to be related to the changes for #22598. An empty ProducesRequestCondition returns a constant EMPTY_CONDITION instead of this which causes it to lose the configured ContentNegotiationManager, which in Spring Boot falls back on "text/html" by default.

[mixcloud-downloader]

Thanks for addressing that issue.

I have a small question regarding this. I try to add a test to my application which would basically do the same as in the referenced example, i.e. make a request against a non existing URI and check the response code. Now, locally the test works as expected (fails with 406 in Spring-Boot-2.1.4 and succeeds with 404 in Spring-Boot-2.1.3). But for whatever reason when I let it run in GitLab's CI (which is the maven:3-jdk-11 docker image) the test even succeeds with a 404 with the broken Spring-Boot-2.1.4. Do you by any chance have any idea why it could succeed?

[rstoyanchev]

The issue was related to comparing two error handling methods and ignoring the "text/html" default content type preference. It's possible the two methods were ordered differently.