Let’s say you make an HTTP request, OkHttp caches ...

# squarelibraries

[arekolek]

Let’s say you make an HTTP request, OkHttp caches it, the user changes system clock to be one day in the past, you try to do the same request again and all you get is the cached response.

Is there anything you can do about it (while still relying on cache)?

[Amirul Zin]

If your cache behavior is just only checking on the device time and not some sort of ETAG, then unless you use something like Instacart TrueTime / do a NTP check manually per request, your cache will take priority.

Some reading: https://android.jlelse.eu/reducing-your-networking-footprint-with-okhttp-etags-and-if-modified-since-b598b8dd81a1

[arekolek]

unless you use something like Instacart TrueTime / do a NTP check manually per request

I’m thinking about OkHttp CacheInterceptor which calls System.currentTimeMillis() anyway. So there is a way to let it know what the true time is despite this?

[louiscad]

@arekolek Can CacheInterecptor be subclassed with this behavior changed?

[arekolek]

There’s a RealCall class that adds it to the list of interceptors, and it doesn’t seem like there’s a way to replace it.

Also, long now = System.currentTimeMillis(); is just one of 93 lines in CacheInterceptor#intercept and CacheInterceptor doesn’t look reusable through subclassing

[louiscad]

I'd open a feature request to allow changing the time source

[arekolek]

I found a similar bug report here https://github.com/square/okhttp/issues/2500