GZIP encoding with `AsyncMiddleManServlet`

[iiliev2]

Jetty Version 12

Jetty Environment
ee8

17

Question
When building a transparent proxy based on AsyncMiddleManServlet how should gzipping be implemented? Do we need to use the GzipHandler, or a AsyncMiddleManServlet.GZIPContentTransformer? The handler's default isSyncFlush is false, which does not work well for a proxy. The server where the AsyncMiddleManServlet is deployed is serving other paths(restapi, etc.), so that handler should ideally be configured with a different syncFlush for different paths(but that is not supported).

[sbordet]

@iiliev2 can you detail your use case?

Is the gzipped content the request content or the response content?

GzipHandler will always try to uncompress the request, before reaching AsyncMiddleManServlet.

If your proxy logic does not need to inspect the request content, you can skip the uncompression and save CPU and latency.
If your proxy logic needs to look at the request content only in certain cases (e.g. certain URLs or certain headers), you can probably use either GZipHandler or GZIPContentTransformer.

On the response side, it depends again on your proxy logic. If you need to inspect the uncompressed response content, you should use GZIPContentTransformer.

You should be able to configure GzipHandler to exclude paths, so you can handle other paths with GzipHandler, and the proxy paths with GZIPContentTransformer.

[iiliev2]

Thanks for your responce. Primary use case is no inspection of the content, but that may come in the future(based on path/headers).

If I understand correctly:

1. We should never mix GzipHandler with GZIPContentTransformer.
2. We do not need the decompression that GzipHandler does in the incomming request.
3. We may want to force compressed encoding between the proxy and the target based on some rules(even if the client did not declare it).
4. We may need decompression for those paths that need to inspect the content(and it is compressed) and this should be done via GZIPContentTransformer.
5. If the client accepts compressed encoding, and the response from the target is already compressed in the same format, we should just pass the bytes through, otherwise we either need to uncompress, or repackage in one of the other acceptable client encodings.

Given all that, it seems that we should just avoid GzipHandler and do (de)compression "manually".