core: support (gzip) compression/decompression

[rebello95]

Overview

We'd like to add support for compressing/decompressing requests/responses (i.e., using gzip or brotli) from within an L7 C++ filter in Envoy Mobile.

Context

Envoy currently supports a gzip filter and corresponding configuration. This filter supports compressing responses from a service based on the size of the response body and other pre-set configurations. However, it does not support decompressing requests.

Goal

Ideally, there are 4 variants of compression/decompression that would be supported in order to transparently support an end-to-end compression solution within Envoy/Envoy Mobile:

	Action	Entity	Supported by Envoy?
1	Compression	Outbound response	YES
2	Decompression	Inbound request	NO
3	Compression	Outbound request	NO
4	Decompression	Inbound request	NO

Implementing this functionality in filter(s) would allow Envoy and Envoy Mobile to make decisions on which requests/responses need to be compressed, and to decompress as necessary.

Changes

An issue was opened in upstream Envoy (envoyproxy/envoy#4445) requesting that decompression of inbound requests be supported. Some work is being done on this already in envoyproxy/envoy#7057 (refactoring the existing gzip filter to more generically act as a "compression" filter), and @rojkov has a branch that goes further down this path.

The Generic Compression Filter proposal document linked in the above discussion also outlines the 4 aforementioned compression options as goals.

I made an upstream change to allow us to force-link the existing gzip filter from Envoy Mobile and was able to test integrating the filter into Envoy Mobile's filter chain. We intend to utilize the compression functionality written into Envoy as it becomes available.

[Augustyniak]

Will it be possible for EnvoyMobile callers (users of EnvoyMobile library) to get access to L4 requests' sizes if we starts gzipping outbound requests using L7 Envoy filter (as mentioned in the write-up above)? Access to L4 sizes would allow us to log them using our analytics pipeline so that we could perform offline analysis on this data.

[rebello95]

That's a good call out, @Augustyniak. Definitely something we should look into and keep top of mind when implementing this feature 👍

[ysirudyl]

Is this being actively worked on? Could you share expected delivery date. I have a use case that depends on envoy supporting gzip compression for incoming requests.

[rebello95]

Yes, this is actively being worked on. @junr03 is wrapping up changes in envoyproxy/envoy#11172, after which we should be able to update Envoy Mobile with the required configs.

[ysirudyl]

Thanks for the update @rebello95. Looks like the pr was minted yesterday. This is exciting!

I'm eager to see this land in mainline so Gloo can expose config for it. Would be sweet if enabling gzip in Envoy for Gloo just goes bi-directional (Response AND Request) by default!

[rebello95]

Resolved by #861 (thank you @junr03 and @rojkov!)