Unexpected behaviour with MediaTypeHeaderDelegate's cached values

[hngu-apple]

We found an interesting issue with Media Type headers in one of our applications. Incoming requests will cache the Accept header value and subsequent requests may return a case-different Content-Type response header. I believe this is technically correct per the RFC https://www.rfc-editor.org/rfc/rfc9110.html#name-media-type but it does not seem like ideal behaviour that clients can impact the case sensitivity of response headers for other clients.

This is the original commit that introduced the cache: ea17ab7

We found this issue after upgrading from 3.6.2.Final -> 4.5.6.Final.

e.g.
Request:
Accept: application/vnd.api+json
Response:
Content-Type: application/vnd.Api+json

Reproducible with this unit test:

import static org.hamcrest.MatcherAssert.assertThat;
import static org.hamcrest.Matchers.is;

import javax.ws.rs.core.MediaType;
import org.jboss.resteasy.plugins.delegates.MediaTypeHeaderDelegate;
import org.junit.jupiter.api.Test;

public class MediaTypeHeaderDelegateTest {

    @Test
    void test() {
        final String lowerCase = "application/vnd.api+json";
        final String upperCase = "application/VND.API+JSON";

        final MediaType mediaTypeLower = MediaTypeHeaderDelegate.parse(lowerCase);
        final MediaType mediaTypeUpper = MediaTypeHeaderDelegate.parse(upperCase);

        assertThat(mediaTypeLower.toString(), is(lowerCase)); <- failing
        assertThat(mediaTypeUpper.toString(), is(upperCase));
    }

}

java.lang.AssertionError: 
Expected: is "application/vnd.api+json"
     but: was "application/VND.API+JSON"
Expected :application/vnd.api+json
Actual   :application/VND.API+JSON

[jamezp]

As you pointed out the media type values are meant to be case-insensitive. I don't think there is much we can do about that, especially with caching enabled.

[hngu-apple]

After doing some more investigation it looks like this was fixed 62ff36b. It's available as early as 4.6.1.Final.

[jamezp]

Ah, good catch.

For my own knowledge, is there something that keeps you on the 4.x releases?

[hngu-apple]

We are following an upgrade path outlined in https://docs.jboss.org/resteasy/docs/4.0.0.Final/userguide/html/Migration_from_older_versions.html to take us from 3.6.2 to 4.5.6. I am not sure about after this but I don't see any reason for us to remain on 4.x after we find some stability.

[jamezp]

Thank you for the insight. One thing to note support for Jakarta REST 2.1 is out of maintenance with Jakarta REST 3.1 and Jakarta REST 4.0 being the two supported API's. RESTEasy 6.2 implements Jakarta REST 3.1 and RESTEasy 7.x implements Jakarta REST 4.0.

The biggest change with these is the javax to jakarta namespace change.

[hngu-apple]

Thanks for the help James. Going to close this issue as resolved.