Almacenamiento en caché de respuestas basadas en encabezados de fecha y edad

Jan 17 2021

Estamos viendo un comportamiento en el que no almacenamos en caché las respuestas en OkHttp y terminamos accediendo al servidor cada vez. Sin embargo, la respuesta tiene una fecha de caducidad en el futuro, por lo que lo ideal sería que se almacenara en caché.

Aquí hay un ejemplo simple de encabezados que estamos viendo en la respuesta (la solicitud se envió y la respuesta se recibió en 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

Por lo que he visto al mirar CacheStrategy, el problema es que suma la fecha y la edad para ver si ha pasado el tiempo de caducidad. En este caso, 00:40:36 + 6 = 00:40:42 > 00:40:40termina por no ser agregado a la caché.

Entonces, creo que idealmente, o la fecha de respuesta sería igual a la última modificación (en este caso, sábado, 16 de enero de 2021 00:40:30 GMT), o necesitaríamos tener una CacheStrategy personalizada para usar la última modificación en lugar de fecha para estos cálculos.

Si alguien tiene alguna idea sobre si estoy haciendo suposiciones erróneas o si es preferible una de las opciones anteriores, hágamelo saber. He examinado algunas de las especificaciones para los encabezados de fecha / edad y no me queda un poco claro cuáles deberían ser en este escenario.

También me resultó un poco difícil depurar el comportamiento de almacenamiento en caché en OkHttp, en este momento solo he estado usando puntos de interrupción condicionales para tratar de rastrearlo, pero si alguien tiene una mejor idea, lo agradecería también.

Respuestas

2 JesseWilson Jan 22 2021 at 11:32

Reemplace el expiresencabezado con un encabezado Cache-Control que establece una directiva de edad máxima:

Cache-Control: max-age=86400

Esto hará que OkHttp almacene en caché la respuesta durante 24 horas, independientemente de cuándo se sirvió. El encabezado expires fue problemático porque CloudFlare lo trató como un tiempo de vencimiento específico, no como una duración.

1 Menelaos Jan 26 2021 at 01:57

Recomendaría intentar usar el encabezado "Cache-Control" con uno max-agede su elección.

La razón principal por la que hago esto es porque esto también se muestra en un ejemplo de la documentación oficial, consulte: https://square.github.io/okhttp/interceptors/#rewriting-responses

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

La forma preferida de hacer esto es obviamente en el back-end. Si no puede modificar el back-end, supongo que un interceptor sería una segunda opción. Tenga en cuenta que es una última opción que se desaconseja.

Además de su backend, también echaría un vistazo a las opciones que ofrece cloudflare: https://support.cloudflare.com/hc/en-us/articles/360021806811-Getting-Started-with-Cloudflare-Caching