Bug in proxy-cache plugin returning compressed cached content to clients not supporting compression

[tobiasehlert]

Is there an existing issue for this?

• [X] I have searched the existing issues

Kong version ($ kong version)

Kong Enterprise 3.6.1.1

Current Behavior

I've got reports from users from my API that they get compressed output when the response was cached from another user.

Lets say for instance a /api/healthz page is called from one client with gzip compression enabled and then another client makes straight away another call to the same endpoint, then the second client is served the compressed cached content but in a not readable format.

Expected Behavior

I expected that the proxy-cache plugin does take the compression part in consideration and returns a non-compressed content to the second client.

Or maybe something some possibility to convert compressed cached content to non-compressed content? I don't know exactly.

Steps To Reproduce

1. add proxy-cache plugin to a route
2. run curl command with compression enabled

   curl --compressed https://example.com/api/healthz -v --output -
   

3. run curl command without compression right afterwards

   curl https://example.com/api/healthz -v --output -
   

Anything else?

This is my Kubernetes resource:

apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: my-cache-1min
  namespace: my-api-v4
config:
  cache_ttl: 60
  content_type:
    - text/plain
    - application/json
    - application/json; charset=utf-8
  request_method:
    - GET
    - HEAD
  response_code:
    - 200
  ignore_uri_case: true
  strategy: memory
plugin: proxy-cache

[StarlightIbuki]

I'm unsure if we should consider this a bug or a possible improvement. But we could fix this and there's a workaround. You could use vary_headers to include "Accept-Encoding" in the cache key so they will be considered different responses. The default behavior is not very reasonable. 2 quick ideas:

1. add the "Accept-Encoding" as the default value;
2. handle different encoding especially

[git-hulk]

@StarlightIbuki @chronolaw Can you take a look at #12876 while you get time?

[StarlightIbuki]

@git-hulk Thanks for your contribution. I'm going to review it soon.

[github-actions[bot]]

This issue is marked as stale because it has been open for 14 days with no activity.

[tobiasehlert]

@StarlightIbuki, how is the progress on the review on #12867? Saw you approved it but needed to check internally :)