The check for whether a mime type is gzipable modifies (lower-cases) the content type

[nickebbitt]

Jetty version

9.4.x (possibly others too)

Java version
1.8

OS type/version
Linux

Description
I'm not sure if this is by design or an issue but if you configure the GzipHandler a custom mime type in its include list that contains upper case characters, e.g. application/json+CUSTOM, then the handler fails to match the content type and therefore does not compress the response.

I've tracked this down to the following code:
https://github.com/eclipse/jetty.project/blob/jetty-9.4.x/jetty-server/src/main/java/org/eclipse/jetty/server/handler/gzip/GzipHttpOutputInterceptor.java#L174

I'm aware that MIME types are generally lower-case by convention so it's possibly a design choice so does it make sense for both sides of the comparison to be lower-cased? If not a bug, is there any value in clarifying the behaviour in the docs?

[joakime]

As a workaround configure GzipHandler with the lowercase version, your use of the mixed case version from your application should still trigger.

Per https://tools.ietf.org/html/rfc7231#section-3.1.1.1
The type is case-insensitive in use.

In practice, Jetty operates on them in a lower-case version in code, but uses the case as-is from the application if the application is using HTTP/1.1 (or HTTP/1.0)
If the application is using HTTP/2 then the case is forced to lowercase to satisfy the HTTP/2 spec.

[nickebbitt]

Thanks for the info @joakime - I had implemented the GzipHandler with the lower case version as you suggest and this works as expected.