HTTP
Cachear las respuestas HTTP

Android Angular 2 AngularJS C# Language HTML Java Language JavaScript Node.js PHP Python Language
Buscar..


Observaciones

Las respuestas se almacenan en caché por separado para cada URL y cada método HTTP.

El almacenamiento en caché de HTTP se define en RFC 7234 .

Glosario

  • fresco : estado de una respuesta en caché, que aún no ha caducado. Normalmente, una respuesta nueva puede satisfacer las solicitudes sin necesidad de contactar con el servidor del que se originó la respuesta.
  • obsoleto : estado de una respuesta almacenada en caché, que ha pasado su fecha de caducidad. Normalmente, las respuestas obsoletas no pueden usarse para satisfacer una solicitud sin verificar con el servidor si sigue siendo válida.
  • satisfacer : la respuesta en caché satisface una solicitud cuando todas las condiciones en la solicitud coinciden con la respuesta en caché, por ejemplo, tienen el mismo método HTTP y URL, la respuesta es nueva o la solicitud permite respuestas obsoletas, los encabezados de solicitud coinciden con los encabezados enumerados en el encabezado Vary la respuesta, etc. .
  • revalidación : comprobar si una respuesta en caché es nueva. Esto generalmente se hace con una solicitud condicional que contiene If-Modified-Since o If-None-Match y el estado de respuesta 304 .
  • caché privado : caché para un solo usuario, por ejemplo, en un navegador web. Los cachés privados pueden almacenar respuestas personalizadas.
  • caché pública : caché compartida entre muchos usuarios, por ejemplo, en un servidor proxy. Tal caché puede enviar la misma respuesta a múltiples usuarios.

Respuesta de caché para todos por 1 año.

Cache-Control: public, max-age=31536000

public significa que la respuesta es la misma para todos los usuarios (no contiene ninguna información personalizada). max-age es en segundos a partir de ahora. 31536000 = 60 * 60 * 24 * 365.

Esto se recomienda para activos estáticos que nunca deben cambiar.

Caché de respuesta personalizada por 1 minuto.

Cache-Control: private, max-age=60

private especifica que la respuesta se puede almacenar en caché solo para el usuario que solicitó el recurso y no se puede reutilizar cuando otros usuarios solicitan el mismo recurso. Esto es apropiado para respuestas que dependen de las cookies.

Deje de usar los recursos en caché sin consultar primero con el servidor

Cache-Control: no-cache

El cliente se comportará como si la respuesta no estuviera en caché. Esto es apropiado para recursos que pueden cambiar de forma impredecible en cualquier momento, y que los usuarios siempre deben ver en la última versión.

Las respuestas con no-cache serán más lentas (latencia alta) debido a la necesidad de contactar al servidor cada vez que se usan.

Sin embargo, para ahorrar ancho de banda, los clientes aún pueden almacenar dichas respuestas. Las respuestas con no-cache no se utilizarán para satisfacer las solicitudes sin ponerse en contacto con el servidor cada vez que se compruebe si la respuesta en caché se puede reutilizar.

Solicitar respuestas para no ser almacenadas en absoluto

 Cache-control: no-store

Indica a los clientes que no almacenen en caché la respuesta de ninguna manera y que la olviden lo antes posible.

Esta directiva se diseñó originalmente para datos confidenciales (hoy se debe usar HTTPS en su lugar), pero se puede usar para evitar caches contaminantes con respuestas que no se pueden reutilizar.

Es apropiado solo en casos específicos donde los datos de respuesta siempre son diferentes, por ejemplo, un punto final de API que devuelve un gran número aleatorio. De lo contrario, no-cache se puede usar la no-cache y la revalidación para tener un comportamiento de respuesta "no almacenable", al mismo tiempo que se puede ahorrar algo de ancho de banda.

Cabeceras obsoletas, redundantes y no estándar

  • Expires : especifica la fecha en que el recurso se vuelve obsoleto. Se basa en servidores y clientes que tienen relojes precisos y zonas horarias compatibles correctamente. Cache-control: max-age tiene prioridad sobre Expires , y generalmente es más confiable.

  • post-check directivas post-check y pre-check son extensiones no estándar de Internet Explorer que permiten el uso de respuestas obsoletas. La alternativa estándar es stale-while-revalidate .

  • Pragma: no-cache - obsoleto en 1999 . Cache-control debe utilizarse en su lugar.

Cambio de recursos en caché

El método más sencillo para omitir el caché es cambiar la URL. Esto se usa como una mejor práctica cuando la URL contiene una versión o una suma de comprobación del recurso, por ejemplo 

http://example.com/image.png?version=1
http://example.com/image.png?version=2

Estas dos URL se almacenarán en caché por separado, por lo que incluso si …?version=1 se almacenó en caché para siempre , una nueva copia podría recuperarse inmediatamente como …?version=2 .

Por favor, no utilice URLs aleatorias para evitar cachés. Use Cache-control: no-cache o Cache-control: no-store lugar. Si las respuestas con direcciones URL aleatorias se envían sin la directiva de no-store , se almacenarán innecesariamente en cachés y expulsarán respuestas más útiles fuera de la memoria caché, lo que degradará el rendimiento de toda la memoria caché.



Modified text is an extract of the original Stack Overflow Documentation
Licenciado bajo CC BY-SA 3.0
No afiliado a Stack Overflow