Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
1 task done
tobiasehlert opened this issue Mar 27, 2024 · 10 comments · May be fixed by #12867
Open
1 task done
Labels
good first issue Issues that beginners/volunteers can easily help with. pinned Issues that won't be marked as stale by stalebot

Comments

@tobiasehlert
Copy link
Contributor

Is there an existing issue for this?

  • 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
Copy link
Contributor

StarlightIbuki commented Apr 1, 2024

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

@StarlightIbuki StarlightIbuki added the good first issue Issues that beginners/volunteers can easily help with. label Apr 1, 2024
@chronolaw chronolaw added the pending author feedback Waiting for the issue author to get back to a maintainer with findings, more details, etc... label Apr 7, 2024
@git-hulk
Copy link
Contributor

git-hulk commented Apr 16, 2024

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

@StarlightIbuki
Copy link
Contributor

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

Copy link
Contributor

github-actions bot commented May 2, 2024

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

@github-actions github-actions bot added the stale label May 2, 2024
@tobiasehlert
Copy link
Contributor Author

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

@github-actions github-actions bot removed the stale label May 3, 2024
Copy link
Contributor

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

@github-actions github-actions bot added the stale label May 18, 2024
@StarlightIbuki
Copy link
Contributor

@tobiasehlert It's still pending decisions.

Copy link
Contributor

github-actions bot commented Jun 4, 2024

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

@github-actions github-actions bot added the stale label Jun 4, 2024
Copy link
Contributor

Dear contributor,

We are automatically closing this issue because it has not seen any activity for three weeks.
We're sorry that your issue could not be resolved. If any new information comes up that could
help resolving it, please feel free to reopen it.

Your contribution is greatly appreciated!

Please have a look
our pledge to the community
for more information.

Sincerely,
Your Kong Gateway team

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Jun 11, 2024
@github-actions github-actions bot removed the stale label Jun 13, 2024
Copy link
Contributor

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

@github-actions github-actions bot added the stale label Jun 27, 2024
@StarlightIbuki StarlightIbuki removed stale pending author feedback Waiting for the issue author to get back to a maintainer with findings, more details, etc... labels Jul 1, 2024
@hanshuebner hanshuebner added the pinned Issues that won't be marked as stale by stalebot label Jul 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Issues that beginners/volunteers can easily help with. pinned Issues that won't be marked as stale by stalebot
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants