You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
we index all our data by locale, and we have an edge service normalize the accept-language request header for the given request.
I was trying to test this with mock mvc using the default boot locale resolver that just uses accept-language request header, but it did not work as expected.
This appears to be because MockHttpServletRequestBuilder and MockHttpServletRequest do not interpret the Accept-Language header at any point when implementing getLocale(). Since getLocale() is kind of fundamental to java servlet & AcceptHeaderLocaleResolver depends on this fundamentalness since it doesn't actually check the Accept-Language header directly, i think the mockers should be a little more knowledgeable about such a header.
however, I'm not sure if these are intentionally dumb. at some point the special handling of the Content-Type request header was removed from MockHttpServletRequest and that is a very similar case.
I'm not super comfortable with relying on locale() in my mock builder as it's not really verifying the incoming accept-language header is what's being respected.
If there's some direction i should follow i'd submit a PR
So you're currently setting the Accept-Language header in your tests? I'm wondering why not just use the locale methods on MockHttpServletRequestBuilder? We could add special handling for the Accept-Language header. That would be merely a convenience, it doesn't add value from an integration testing perspective since it's not the Servlet container parsing the headers.
i do have tests with locale...but then anything that calls getHeader("accept-language") doesn't sync up
as mentioned in description:
I'm not super comfortable with relying on locale() in my mock builder as it's not really verifying the incoming accept-language header is what's being respected.
Right I see it now. AcceptHeaderLocaleResolver relies on request.getLocale() but in 4.3 there was an extra check added for the presence of Accept-Language.
Chris DaMour opened SPR-15209 and commented
we index all our data by locale, and we have an edge service normalize the accept-language request header for the given request.
I was trying to test this with mock mvc using the default boot locale resolver that just uses accept-language request header, but it did not work as expected.
This appears to be because MockHttpServletRequestBuilder and MockHttpServletRequest do not interpret the Accept-Language header at any point when implementing getLocale(). Since getLocale() is kind of fundamental to java servlet & AcceptHeaderLocaleResolver depends on this fundamentalness since it doesn't actually check the Accept-Language header directly, i think the mockers should be a little more knowledgeable about such a header.
however, I'm not sure if these are intentionally dumb. at some point the special handling of the Content-Type request header was removed from MockHttpServletRequest and that is a very similar case.
I'm not super comfortable with relying on locale() in my mock builder as it's not really verifying the incoming accept-language header is what's being respected.
If there's some direction i should follow i'd submit a PR
Affects: 4.3.6
Issue Links:
The text was updated successfully, but these errors were encountered: