GzipHandler should support prefix based mime-type matching for include/exclude

[jmcc0nn3ll]

migrated from Bugzilla #462417
status ASSIGNED severity enhancement in component server for 9.3.x
Reported in version unspecified on platform All
Assigned to: Project Inbox

On 2015-03-17 17:37:12 -0400, brian clozel wrote:

gzipping HTTP responses can be achieved by configuring a GzipHandler with allowed and excluded mime types.

Nowadays many applications make use of custom Media Types; those types can change over time and are more and more an application concern.

Is there a way to configure response compression for multiple mime types without listing them all in the configuration?

Maybe comparing mimetypes (see rfc2046 and rfc7231 section-3.1.1.1) could be a nice way of doing this, basically by allowing wildcards in configured mimetypes and breaking each mimetype in "type/subtype+suffix".

• "text/*" is compatible with "text/html" and "text/plain"
• "application/*+json" is compatible with all Github custom mediatypes (see https://developer.github.com/v3/media/)

On 2015-03-17 17:49:19 -0400, brian clozel wrote:

Note: Tomcat is doing this with a much simpler approach: it's checking if the response content-type starts with any of the configured ones.

So configuring "application/vnd.github" as an acceptable type would work for all github mimetypes.

On 2015-03-17 18:17:56 -0400, Greg Wilkins wrote:

Brian,

note that you can configure excluded mime types rather than included ones, which may assist in being less verbose in configuration.

Note that by default, it goes through the known mime types and excludes anything starting with

        if (type.startsWith("image/")||
            type.startsWith("audio/")||
            type.startsWith("video/"))

However, I guess the excluded ones will also change moderately frequently and there will be new discoveries at run time, so having some kind of wildcard match would make that easier. I would make it an explicit wildcard rather than always a prefix.

So we will look at this once we find some time.... however contributions more than welcome (maybe a github pull request?)

[joakime]

Note: the GzipHandler is the place for this kind of fix now.

[gregw]

No plans to implement this