-
-
Notifications
You must be signed in to change notification settings - Fork 935
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Cache not decompressed before attempting to JSON.parse #1158
Labels
bug
Something does not work as it should
Comments
This appears to be fixed when using |
Can you set up a RunKit example please? |
Closed
Please make an issue in the |
Reproduced in the example above, will now make a test. |
Fixed in 6ca17e2 |
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
Describe the bug
v10.15.3
When using the request cache with
decompress: true, responseType: 'json'
, the first request succeeds. For a response with a 60s ttl, the next 60s of requests succeed too.Then, when it comes to revalidating the cache, a 304 response is returned, and an error is thrown.
so
Actual behavior
The cached response is gzipped, which is then not decompressed again (it seems), which means JSON.parse throws an error as it's trying to parse bytes...
Expected behavior
We expect the cached body to be used. I'd also prefer the cache to be decompressed, so each call to the cache uses less CPU.
Code to reproduce
The URL in question responds with
cache-control: public,max-age:60
andetag
headers.Setting
decompress: false
fixes the issueChecklist
The text was updated successfully, but these errors were encountered: