Expected Behavior

In an application, we have to deal with a cookie containing the name of a store. As we are in France, this name can contains accents.

If I send storeName=REZÉ, I expect to receive REZÉ in storeName.

Current Behavior

I got a RequestRejectedException because the header is invalid.

The use of force encoding to UTF-8 does not change anything.

Context

I found that Cookies are decoded in ISO_8859_1. So REZÉ becomes REZÉ in Spring. So the StrictHttpFirewall is not able to validates this header value.

I had to create a new predicate to retrieves the UTF8 version of the header value.

public final class Utf8AllowedHeaderValuesPredicate implements Predicate<String> {

    private final static Pattern ALLOWED_PATTERN = Pattern.compile("[\\p{IsAssigned}&&[^\\p{IsControl}]]*");

    @Override
    public boolean test(String s) {
        String utf8Value = new String(s.getBytes(Charset.forName("ISO_8859_1")), StandardCharsets.UTF_8);
        return ALLOWED_PATTERN.matcher(utf8Value).matches();
    }
}

@Configuration
public class SomeConfiguration {
   @Bean
    public StrictHttpFirewall httpFirewall() {
        StrictHttpFirewall firewall = new StrictHttpFirewall();
        firewall.setAllowedHeaderValues(new Utf8AllowedHeaderValuesPredicate());
        return firewall;
    }
}

I had to copy the allowed pattern of StrictHttpFirewall because it allows utf-8 characters and I had to convert the header value from ISO_8859_1 to UTF_8.

Maybe Cookies should be allowed to be forced to UTF-8 when needed.

Comment From: eleftherias

Thanks for reaching out @ecattez. I gave this a try, but I wasn't able to reproduce the behaviour you are seeing, since the cookie values appeared as expected (REZÉ) in my application. Could you please share a minimal sample that reproduces this issue?

Comment From: ecattez

I took a screenshot from what I have on the browser-side and what I get from the server side. As a reminder, this cookie does not belong to us directly. It is cross-team.

capture_cookie_backend capture_cookie_browser

Comment From: eleftherias

Thanks for the additional details @ecattez. I am not able to reproduce this, the validateAllowedHeaderValue method does not throw a RequestRejectedException in the application that I am using. Could you please share a minimal sample that reproduces this issue, so that we can investigate it further.