根据日期和年龄标头缓存响应

我们看到一些行为，我们没有在 OkHttp 中缓存响应，最终每次都会访问服务器。然而，响应在未来有一个过期时间，所以理想情况下它会被缓存。

以下是我们在响应中看到的标头的简单示例（在 Sat,16 Jan 2021 00:40:36 GMT 发送请求和接收响应）：

date: Sat,16 Jan 2021 00:40:36 GMT
age: 6
expires: Sat,16 Jan 2021 00:40:40 GMT
last-modified: Sat,16 Jan 2021 00:40:30 GMT

从我查看 CacheStrategy 所看到的情况来看，问题在于它将日期 + 年龄相加以查看它是否已超过到期时间。在这种情况下，00:40:36 + 6 = 00:40:42 > 00:40:40，因此它最终不会被添加到缓存中。

所以我认为理想情况下，要么响应日期等于上次修改日期（在本例中为 2021 年 1 月 16 日星期六，格林威治标准时间 00:40:30），要么我们需要有一个自定义的 CacheStrategy 来使用 last-修改而不是这些计算的日期。

如果有人对我是否做出了错误的假设有任何见解，或者上述选项之一是否更可取，请告诉我。我已经查看了日期/年龄标题的一些规范，但我有点不清楚在这种情况下它们应该是什么。

我还发现在 OkHttp 中调试缓存行为有点困难，现在我只是使用条件断点来尝试跟踪它，但如果有人有更好的主意，我也会很感激.

用设置 max-age 指令的 Cache-Control 标头替换 expires 标头：

Cache-Control: max-age=86400

这将导致 OkHttp 将响应缓存 24 小时，而不管它何时被提供。 expires 标头有问题，因为 CloudFlare 将其视为特定的到期时间，而不是持续时间。

我建议尝试使用带有您选择的 max-age 的“Cache-Control”标头。

我这样做的主要原因是因为这也在官方文档的示例中显示，请参阅：https://square.github.io/okhttp/interceptors/#rewriting-responses

.header("Cache-Control","max-age=60")

执行此操作的首选方法显然是在后端。如果您不能修改后端，那么我想拦截器将是第二个选择。 请注意，这是最后一个不鼓励的选项。