Summary

Provide a way to set the content encoding to Brotli (or other way), other than gzip compression

Background

Vendor tried serving javascript through a servlet, a gzip compression will be automatically applied by Confluence if the content encoding is set to application/javascript (or other similar types).

This works well in general, but as we try to use a different content encoding scheme (e.g. brotli) to serve the javascript, a gzip compression is still applied even if the servlet explicitly set the content-coding to be "br" in the response header. As a result, the browser receives the content with gzip compression on top of brotli compressed javascript.

Workaround

Vendor tried manually setting the Content-Type in the response header to be something which won't be gzipped automatically. But that is causing other issues.

Suggestion

Having a way to give an add-on servlet full control over the HTTP response, without any filtering, is a reasonable expectation. Gzip filter should definitely NOT get applied if there is already a `Content-Encoding` response header (alternatively, the filter can check for some custom header, e.g. `X-Enable-Gzip-Filter: false`).