Gzip compression not working for multipart/form-data when added to the allowed list using addIncludedMimeTypes.

[rjonna]

Jetty version(s)
9.4.22.v20191022

Java version/vendor (use: java -version)
openjdk 16.0.1 2021-04-20

OS type/version
Linux

Description
When multipart/form-data is added to the allowed list using addIncludedMimeTypes, compression is not being applied because of the boundary parameter. Getting the following error.
2022-02-10 21:57:55,024 DEBUG [qtp112619572-112] org.eclipse.jetty.server.handler.gzip.GzipHttpOutputInterceptor - org.eclipse.jetty.server.handler.gzip.GzipHttpOutputInterceptor@3e373008 exclude by mimeType multipart/form-data;boundary=Boundary_2_393478717_1644530275023

Included it like this:

<Call name="addIncludedMimeTypes">
    <Arg>
    <Array type="String">
       <Item>application/json</Item>
        <Item>multipart/form-data</Item>
    </Array>
    </Arg>
</Call>

The comment for addIncludedMimeTypes says "@param types The mime types to include (without charset or other parameters)" but only charset is being removed but not the boundary. https://github.com/eclipse/jetty.project/blob/jetty-10.0.x/jetty-server/src/main/java/org/eclipse/jetty/server/handler/gzip/GzipHandler.java#L697

Usually, multipart/form-data is followed by other parameters and other parameters are not removed while checking the condition, hence compression is likely to always fail for multipart/form-data when added to the allowed list.

Is this a bug? Is there any work around?

[joakime]

You should do 2 things.

First upgrade your version of Jetty.
Use 9.4.45.v20220203 - as that's on the same servlet + major version as you are currently using.
This version contains fixes in multipart AND fixes in Gzip that you need.

Next, configure your HttpConfiguration.setMultiPartFormDataCompliance(MultiPartFormDataCompliance.RFC7578) for your chosen ServerConnector. (default behavior in Jetty 9.x is LEGACY and it has the warts/bugs that you are experiencing, switch to the spec compliant version instead. Note that Jetty 10, Jetty 11, and Jetty 12 ONLY have the spec compliant multi-part mode, and have dropped the LEGACY behavior).

[rjonna]

@joakime - We already have RFC7578 compliance and the new version also doesn't work, getting the same error. It is due to the boundary field not being stripped when doing the comparison. The comparison is an exact string match. Our multipart content type(multipart/form-data;boundary=Boundary_2_393478717_1644530275023) is according to the spec.

Btw, this is the compression on the response from server to client (not the request). Any other thoughts?

[joakime]

@lachlan-roberts can you take a look?

[lachlan-roberts]

@rjonna I think the comparison of the mime type should be done without the parameters.

You could possibly work around this by excluding the mime types you don't want to gzip instead of including the ones you do. But I will propose a fix for this in a PR.

[rjonna]

@lachlan-roberts - Yes, mime type comparison has to be done without the parameters. Thanks so much for the quick fix.

[lachlan-roberts]

I have merged the fix to 9.4.x, 10.0.x and 11.0.x.
So this will be fixed for you in the next release.

[rjonna]

Thank you so much.