MockHttpServletResponse doesn't propagate Content-Language response header [SPR-17284]

[spring-projects-issues]

Michał Szymborski opened SPR-17284 and commented

When trying to test our language fallback scenario using spring-test, I've noticed that the following scenario is failing, while it works just fine when reproduced with curl (the actual content of the test has been replaced due to the proprietary nature of the project):

 

mockMvc.perform(post(SOME_URL)
     .header(HttpHeaders.ACCEPT_LANGUAGE, NOT_SUPPORTED_LANGUAGE)
     .content(serializeRequest()))
     .andExpect(header().string(HttpHeaders.CONTENT_LANGUAGE, FALLBACK_LANGUAGE));{color}

 
As I ventured on to find the cuplrit I've noticed that this is handled as a special case of a header in MockHttpServletResponse:

 

[https://github.com/spring-projects/spring-framework/blob/v5.0.9.RELEASE/spring-test/src/main/java/org/springframework/mock/web/MockHttpServletResponse.java#L592]{color}

 
After the locale is set, unlike in the first two if cases, the header is not actually added to the response, causing failure in the tests. For reference this is how the header is set in the controller:

 

return ResponseEntity
    .status(HttpStatus.OK)
    .header(HttpHeaders.CONTENT_LANGUAGE, language)
    .body(serializedDto);{color}

I would expect the header to actually be set, unless there's something I've missed when browsing through the mechanism - if so, I would love if you could point me to the relevant resources to understand this better.

---

Affects: 5.0.9

Issue Links:

• Mock MVC / RequestBuilder should handle Accept-Language header appropriately [SPR-15209] #19773 Mock MVC / RequestBuilder should handle Accept-Language header appropriately

Referenced from: commits d551710, 1489457

Backported to: 5.0.10

[spring-projects-issues]

Rossen Stoyanchev commented

Support for setting the Content-Language header was introduced relatively recently, in 5.0 RC1 #19773. Then it looks like an accidental regression was introduced in #cc74a2 in 5.0 RC3, so in effect this never did work as expected in a GA release.

[spring-projects-issues]

Juergen Hoeller commented

This seems like an accident indeed, dating back to the original code that meant to be able to set null there. After this having been changed to Locale.getDefault() thereafter anyway, I see no issue with a straight setLocale call now.