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
All cacheKey override on Request. #8211
Comments
Can you link to how browsers remove the transient params? |
As a kludgy workaround, you can use application and network interceptors to modify what gets evaluated for caching, and what gets sent on the wire. But we should consider a proper cache key API. Or learn from browsers on transient params?
|
See |
Thank you for the suggestion. I'll see if I can make it work. |
That Cache seems like a specific web workers thing, slightly detached from fetch. https://developer.mozilla.org/en-US/docs/Web/API/Cache So not sure we want to make our Cache the same thing. And it doesn't seem like it applies to the fetch API calls. But still worth working out how to support |
Here is an example how self.addEventListener('fetch', event => {
if (event.request.method != 'GET') {
return;
}
event.respondWith((async _ => {
// Try to find the response in the cache.
const cache = await caches.open(PACKAGE_VERSION);
const reqUrl = new URL(event.request.url);
// Using ignoreSearch=true to read cached images and docs despite different auth signatures.
const cachedResponse = await cache.match(event.request, {ignoreSearch: (self.location.origin == reqUrl.origin)});
if (cachedResponse) {
return cachedResponse;
}
// Not found in cache.
const response = await fetch(event.request);
if (!response || response.status != 200 || response.type != 'basic') {
return response;
}
if (reqUrl.protocol == 'http:' || reqUrl.protocol == 'https:') {
await cache.put(event.request, response.clone());
}
return response;
})());
}); |
Yep, understood. It's not a HTTP cache (honouring cache headers) It's a specific web worker cache for Request/Response. Might be interesting to allow for a cache only request without going through with a call. |
I'm going to close, I don't think we can copy the WebWorker Cache, and there is an ugly workaround. |
Is there a plan to address it in any ("right") way or no plan at all? I need to make the decision to keep Picasso (which relies on okhttp cache) or switch to Glide. If there is no plan then I have to byte the bullet and switch. Thanks. |
The fix in okhttp could be trivially simple. Make class |
We have a similar requirement for a cache key for DoH DNS caching. #8113 So maybe as part of that. This might be some optional tag for a cache key if it's not just POST. |
We have a similar requirement for a cache key for DoH DNS caching. #8113 So maybe as part of that. @swankjesse any thoughts? |
Yes, looks similar. The simplest solution would be to allow users to provide a custom implementation of the |
Similar requests #1605 |
I'll reopen for further discussion |
BTW, #8113 would likely require passing the entire |
It's unlikely we would open up Cache for subclassing, we are very careful about new public API surface. So more likely some way to specify the cache key for a request. |
I’m glad this issue was reported before we proceeded on #8113. I’m tempted to do a |
Yep, let's do it. Does the override on otherwise non cacheable requests affect just the initial cache search, or also update the cache if a miss? or stays uncacheable? |
Signed URLs, such as https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-presigned-url.html, include a transient token as a query parameter. Okhttp provides no facility to filter out transient query parameters (or, in fact, no facility at all to customize cache lookups) for the purpose of caching. Such objects are effectively never cached by okhttp. Furthermore, nearly every class in okhttp is
final
making it impossible to add such functionality by subclassing.Javascript in browsers has this facility. You should too.
See this asked (and ignored) at stackoverflow: https://stackoverflow.com/questions/40783613/how-to-custom-cache-in-okhttp3
The text was updated successfully, but these errors were encountered: