Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

spring-projects-issues opened this issue Sep 18, 2018 · 2 comments
in: test status: backported type: bug


Copy link

@spring-projects-issues spring-projects-issues commented Sep 18, 2018

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):


     .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:



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
    .header(HttpHeaders.CONTENT_LANGUAGE, language)

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:

  • #19773 Mock MVC / RequestBuilder should handle Accept-Language header appropriately

Referenced from: commits d551710, 1489457

Backported to: 5.0.10

Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Oct 2, 2018

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.

Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Oct 2, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
in: test status: backported type: bug
None yet

No branches or pull requests

2 participants