AcceptHeaderLocaleResolver ignores defaultLocale when Accept-Language header is present but blank #36512

Bug Description

AcceptHeaderLocaleResolver correctly returns defaultLocale when the Accept-Language header is absent (null), but ignores it when the header is present with a blank value (""), falling back to Locale.getDefault() (JVM system locale) instead.

Current Behaviour

if (defaultLocale != null && request.getHeader("Accept-Language") == null) {
    return defaultLocale;
}

This check only guards against null. A blank "" header value passes through, hits request.getLocale() which delegates to the JVM default locale — ignoring the configured defaultLocale entirely.

Expected Behaviour

A blank Accept-Language header value represents the same intent as an absent header — "no language preference". Both should return defaultLocale when configured.

Steps to Reproduce

AcceptHeaderLocaleResolver resolver = new AcceptHeaderLocaleResolver();
resolver.setDefaultLocale(Locale.forLanguageTag("az"));
resolver.setSupportedLocales(List.of(Locale.forLanguageTag("az")));

MockHttpServletRequest request = new MockHttpServletRequest();
request.addHeader("Accept-Language", "");  // blank, not null

Locale result = resolver.resolveLocale(request);
// actual:   en  (JVM default)
// expected: az  (configured defaultLocale)

Proposed Fix

String acceptLanguage = request.getHeader("Accept-Language");
if (defaultLocale != null && (acceptLanguage == null || acceptLanguage.isBlank())) {
    return defaultLocale;
}

Environment

• Spring Framework 6.x
• Reproducible via curl: curl --header 'Accept-Language;' sends the header with an empty string value, which Tomcat parses as accept-language = "" (confirmed via MimeHeaders debug logging)
• JVM default locale affects result — behaviour differs across environments