-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
Do not cache user-initiated Refresh Status requests from the client #15154
Comments
We'll want to modify our |
I could be mistaken, but I don't think there's client caching judging by the call chain of There's possibly a couple of hypothetical edge cases, which might cause this erroneous state we saw, so I think we should investigate further or add instrumentation to help with diagnosis |
@yachtcaptain23 Yeah, we don't cache the request in the client; it's the Chromium network layer that's caching it. You can see this if you send a request, disconnect your Internet, and send another request. Even with the Internet disconnected, Brave will behave as though both requests succeeded. I believe this is happening via this class, but not positive: https://source.chromium.org/chromium/chromium/src/+/master:net/http/http_cache.h. Setting |
Verified
Steps:
|
Removing Android label as there is no refresh button on Android once the publisher status is updated. Follow up issue #15966 for Android |
Do we know if the above fix would also apply to Android? That is, if the user presses "refresh status" on Android, it will always bypass local cache? |
Description
When a user presses "Refresh Status" to get the latest information on a Creator/publisher, this call should never be client-cached so as to always fetch the latest Creator information from the PCDN.
Solution
The network request from the client should always skip any sort of client-side caching. This should be implemented in the browser code.
The text was updated successfully, but these errors were encountered: