Please update https://www.envoyproxy.io/docs/envoy/latest/intro/deprecated. Also are we going to deprecate the standalone gzip filter entirely? Perhaps that should be done in a different change since I think doing the warning/stat dance for that deprecation will not be built-in?cc @zuercher who has been working on this recently.

Also are we going to deprecate the standalone gzip filter entirely?

The filter itself isn't deprecated. Our users shouldn't notice any changes in its functionality except the new deprecation warning on using content_length and other deprecated config fields.

But why would we keep the gzip filter when there is the generic compression filter? Should we deprecate the gzip filter and have users migrate to using the generic compression filter?

The generic filter is not exposed to users directly. The idea was to expose it through a new config field of the existing "gzip" filter. Then to introduce a new filter - "brotli" - exposing the same field.

...
  http_filters:
  - name: envoy.filters.http.gzip
    config:
      compression_level: speed
      compressor:
         remove_accept_encoding_header: true
  - name: envoy.filters.http.brotli
    config:
      quality: 12
      compressor:
         remove_accept_encoding_header: true

This way users would do the transition seamlessly.

If I understood correctly you wanted to keep "gzip" as it was and to expose the generic filter as a normal HTTP filter parameterized with a compression lib config:

...
  http_filters:
  - name: envoy.filters.http.compress
    config:
      remove_accept_encoding_header: true
      compressor_library:
      - name: gzip
        config:
          compression_level: speed
  - name: envoy.filters.http.compress
    config:
      remove_accept_encoding_header: true
      compressor_library:
      - name: brotli
        config:
          quality: 12

This way users may experience unexpected results when both the old gzip and the new generic filter end up in the same filter chain for some reason.

But since this PR has been merged already the gzip filter is capable of cooperation with other compression filters now and users won't get unexpected results.

Still I need to know which way is preferable.

Yes I would definitely prefer the 2nd option, as it's more extensible for the future. I think we should add that, allow the generic compression filter to support gzip, and then deprecate the gzip filter?

Please add a DEPRECATED_FEATURE_TEST that tests the old path.