Qué es Cache-Control: private?

Para responder a su pregunta sobre por qué el almacenamiento en caché está funcionando, a pesar de que el servidor web no incluyó las cabeceras:

• Caduca: [a date]
• Cache-Control: max-age = [seconds]

El servidor amablemente pidió a cualquier proxy intermedio que no almacenara en caché el contenido (es decir, el elemento solo debe almacenarse en caché en una caché privada, es decir, solo en su propia máquina local):

• Control de Caché: privado

Pero el servidor olvidó incluir cualquier tipo de sugerencia de almacenamiento en caché:

• se olvidaron de incluir Caduca , por lo que el navegador sabe usar la copia en caché hasta esa fecha
• se olvidaron de incluir Max-Age , por lo que el navegador sabe cuánto tiempo el elemento almacenado en caché es bueno para
• se olvidaron de incluir E-Tag , por lo que el navegador puede hacer una solicitud condicional

Pero sí incluyeron un Última modificación fecha de la respuesta:

Last-Modified: Tue, 16 Oct 2012 03:13:38 GMT

Debido a que el navegador conoce la fecha en que se modificó el archivo, puede realizar un "solicitud condicional". Le preguntará al servidor por el archivo, pero le indicará que solo envíe el archivo si se ha modificado desde entonces 2012/10/16 3:13:38:

GET / HTTP/1.1
If-Modified-Since: Tue, 16 Oct 2012 03:13:38 GMT

El servidor recibe la solicitud, se da cuenta de que el cliente ya tiene la versión más reciente. En lugar de enviar al cliente 200 OK, seguido por el contenido de la página, en su lugar te dice que tu versión en caché es buena:

304 Not Modified

Su navegador tuvo que sufrir el retraso de enviar una solicitud al servidor, y esperar una respuesta, pero se ahorró tener que volver a descargar el contenido estático.

¿Por qué Edad máxima? ¿Por qué Caduca?

Porque Last-Modified apesta.

No todo en el servidor tiene una fecha asociada. Si estoy construyendo una página sobre la marcha, no hay fecha asociada con es-es ahora . Pero estoy perfectamente dispuesto a dejar que el usuario almacene en caché la página de inicio durante 15 segundos:

200 OK
Cache-Control: max-age=15

Si el usuario martillea F5, seguirá obteniendo la versión en caché durante 15 segundos. Si se trata de un proxy corporativo, entonces todos los 67198 usuarios que golpean la misma página en la misma ventana de 15 segundos obtendrán el mismo contenido, todo servido desde la caché de cierre. Rendimiento ganar para todos.

La virtud de agregar Cache-Control: max-age es que el navegador ni siquiera tiene que realizar un solicitud condicional.

• si solo especificó Last-Modified, el navegador tiene que realizar una solicitud If-Modified-Since, y estar atento a una respuesta 304 Not Modified
• si especificó max-age, el navegador ni siquiera tendrá que sufrir el viaje de ida y vuelta de la red; el contenido saldrá directamente de las cachés

La diferencia entre" Cache-Control: max-age "y"Expires"

Expires es un equivalente heredado del encabezado modern (c. 1998) Cache-Control: max-age:

• Expires: usted especifica una fecha (yuck)
• max-age: usted especifica segundos (bondad)

• Y si se especifican ambos, entonces el navegador utiliza max-age:

  200 OK
  Cache-Control: max-age=60
  Expires: 20180403T192837 
  

Cualquier sitio web escrito después de 1998 no debería usar Expires más, y en su lugar usar max-age.

¿Qué es ETag?

ETag es similar a Última Modificación, excepto que no tiene que ser una fecha - sólo tiene que ser un algo.

Si estoy sacando una lista de productos de una base de datos, el servidor puede enviar el último rowversion como un ETag, en lugar de una fecha:

200 OK
ETag: "247986"

Mi ETag puede ser el hash SHA1 de un recurso estático (por ejemplo, image, js, css, font), o de la página renderizada en caché (es decir, esto es lo que hace el wiki MDN de Mozilla; ellos hash el marcado final):

200 OK
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

Y exactamente como en el caso de una solicitud condicional basada en Última Modificación:

GET / HTTP/1.1
If-Modified-Since: Tue, 16 Oct 2012 03:13:38 GMT

304 Not Modified

Puedo realizar una solicitud condicional basada en la ETag:

GET / HTTP/1.1
If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"

304 Not Modified

Un ETag es superior a Last-Modified porque funciona para cosas además de archivos, o cosas que tienen una noción de fecha. Simplemente es

RFC 2616, sección 14.9.1:

Indica que todo o parte del mensaje de respuesta está destinado a un solo usuario y NO DEBE ser almacenado en caché por una caché compartida...Una caché privada (no compartida) PUEDE almacenar en caché la respuesta.

Los navegadores podrían usar esta información. Por supuesto, el "usuario" actual puede significar muchas cosas: usuario del sistema operativo, un usuario del navegador (por ejemplo, los perfiles de Chrome), etc. No está especificado.

Para mí, un ejemplo más concreto de Cache-Control: private es que los servidores proxy (que normalmente tienen muchos usuarios) no lo almacenarán en caché. Está destinado al usuario final y a nadie más.

Para su información, el RFC deja claro que esto no proporciona seguridad. Se trata de mostrar el contenido correcto, no de asegurar el contenido.

Este uso de la palabra privado solo controla donde la respuesta puede ser almacenada en caché, y no puede garantizar la privacidad del contenido del mensaje.

El campo Expires entity-header da la fecha/hora después de la cual la respuesta se considera obsoleta.El campo Cache-control: maxage da el valor de antigüedad (en segundos) más grande que la respuesta que se considera obsoleta.

Aunque el campo de encabezado anterior da un mecanismo al cliente para decidir si enviar una solicitud al servidor. En alguna condición, el cliente envía una solicitud para cortar y el valor de edad de la respuesta es mayor que el valor de maxage, dosis que significa que el servidor necesita enviar el recurso ¿al cliente? Tal vez el recurso nunca cambió.

Para resolver este problema, HTTP1.1 da la última cabeza modificada. El servidor da la última fecha de modificación de la respuesta al cliente. Cuando el cliente necesite este recurso, enviará el campo If-Modified-Since head al servidor. Si esta fecha es anterior a la fecha de modificación del recurso, el servidor enviará el recurso al cliente y le dará 200 códigos.De lo contrario, devolverá el código 304 al cliente y esto significa que el cliente puede usar el recurso que caché.