-
-
Notifications
You must be signed in to change notification settings - Fork 969
Closed
Labels
bugSomething does not work as it shouldSomething does not work as it should
Description
Describe the bug
- Node.js version:
v10.15.3
- OS & version: Amazon Linux + MacOS 10.14.6
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...
GotError: Unexpected token \u001f in JSON at position 0 in \"url-here\"\n at EventEmitter.emitter.on (/Users/simon.tabor/Development/fe-router/node_modules/got/dist/source/as-promise.js:78:40)\n at JSON.parse (<anonymous>)\n at parseBody (/Users/simon.tabor/Development/fe-router/node_modules/got/dist/source/as-promise.js:12:46)\n at EventEmitter.emitter.on (/Users/simon.tabor/Development/fe-router/node_modules/got/dist/source/as-promise.js:72:33)\n at process._tickCallback (internal/process/next_tick.js:68:7)
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
const cache = new Map();
const response = await got(url, {
cache,
responseType: 'json',
decompress: true,
timeout: 5000,
retry: 2,
});
The URL in question responds with cache-control: public,max-age:60
and etag
headers.
Setting decompress: false
fixes the issue
Checklist
- I have read the documentation.
- I have tried my code with the latest version of Node.js and Got.
Metadata
Metadata
Assignees
Labels
bugSomething does not work as it shouldSomething does not work as it should