sindresorhus / got

🌐 Human-friendly and powerful HTTP request library for Node.js
MIT License
14.29k stars 935 forks source link

Overriding caching behaviour (cache even if remote host told me to not do that) #746

Open bago opened 5 years ago

bago commented 5 years ago

Issuehunt badges

What would you like to discuss?

I'd like to override got caching so to extend what the remote headers ask me to do. I currently use the max-stale in the request header to extend somehow the caching, but this doesn't work if the remote service use strict caching headers and got doesn't even store them.

I tried manipulating response headers in the .on('response', ) hook, but this doesn't work. Sounds like got caches the manipulated response, but the cachecontrol is precomputed into a different property and uses the original cache-control.

I guess this is something happending in cacheable-request makeRequest's response handler that calls the ee.emit('response') AFTER storing the response, so maybe I should open an issue against the "cacheable-request" project, but my knowledge of got internals is very limited, so I preferred to start with this question as maybe you can identify a better way or a workaround to alter if and how long got caches a result.

Checklist

There is a $60.00 open bounty on this issue. Add more on Issuehunt.

IssueHuntBot commented 5 years ago

@issuehunt has funded $60.00 to this issue.


rifler commented 5 years ago

my use case: I want to cache every outgoing GET request within current incoming request. I create express middleware

function cacheHttpAdapter(req: Request, res: Response, next: NextFunction) {
    req.cacheHttpAdapter = new Map();

    next();
}

and pass it to got wrapper, similar to described in #723 , because I don't want RFC cache behaviour

It will be much more convenient to manage cache behaviour without any wrappers

szmarczak commented 5 years ago

@sindresorhus can we close this one and move to #875 ?

sindresorhus commented 4 years ago

Let's keep it open so we can use the bounty for this issue for #875 instead. We can close this issue when #875 is closed. I'll lock it instead.