would throw IllegalArgumentException. However in spring-core 5.1.x (tested with 5.1.3.BUILD-SNAPSHOT) it doesn't. It simply returns a java.util.Locale object with language="some-locale-that-does-not-exist", region="", country=""
#21241 CookieLocaleResolver is not RFC6265 compliant when setting a locale and time zone
The text was updated successfully, but these errors were encountered:
As of 5.1, we only really accept "-" as a valid character in locale strings, driven by #21241 and the parsing of RFC6265 language tags. So the reason why that particular test would fail is a side effect of that "-" leniency; we would have accepted any other non-existing locale before and simply accept "-" in such non-existent locale specifications as well now...
Do you see a specific issue with the tolerance of "-" here? Or did you expect StringUtils to reject non-existent locales to begin with?
My expectation was that StringUtils would reject non-existing locales. However I wasn't aware of RFC6265 and it's implications. Having said that I don't really know what the correct behaviour should be.
For many parsing scenarios, this is an inverse operation of Locale's toString, in a lenient sense. This method does not aim for strict Locale design compliance; it is rather specifically tailored for typical Spring parsing needs.