2009-02-18 25 views
13

En el módulo de Apache mod_expires, existe la directiva Expires con dos períodos de base de tiempo, acceso, y modificación.Cache Expire de control con la última modificación

ExpiresByType text/html "access plus 30 days" 

significa comprensible que la memoria caché solicitará el contenido fresco después de 30 días.

Sin embargo,

ExpiresByType text/html "modification plus 2 hours" 

no tiene sentido intuitivo.

¿Cómo sabe el caché del navegador que el archivo se ha modificado a menos que haga una solicitud al servidor? Y si está haciendo una llamada al servidor, ¿para qué sirve almacenar en caché esta directiva? Me parece que no entiendo una parte crucial del almacenamiento en caché. Por favor iluminame.

Respuesta

35

Una directiva Expires* con "modificación" como base hace referencia al tiempo de modificación del archivo en el servidor. Por lo tanto, si establece, por ejemplo, "modificación más 2 horas", cualquier navegador que solicite contenido dentro de las 2 horas posteriores a la modificación del archivo (en el servidor) almacenará dicho contenido en caché hasta 2 horas después de la hora de modificación del archivo. Y el navegador sabe cuándo se debe a que el servidor envía un encabezado Expires con el tiempo de caducidad adecuado.

Me explico con un ejemplo: dicen que la configuración de Apache incluye la línea

ExpiresDefault modification plus 2 hours 

y usted tiene un archivo index.html, que la Directiva se aplica a ExpiresDefault, en el servidor. Supongamos que carga una versión de index.html a las 9:53 GMT, sobrescribiendo la anterior existente index.html (si había una). Entonces ahora el tiempo de modificación de index.html es 9:53 GMT. Si se ejecuta ls -l en el servidor (o dir en Windows), que se vería en la lista:

-rw-r--r-- 1 apache apache 4096 Feb 18 09:53 index.html 

Ahora, con cada petición, Apache envía la cabecera Last-Modified con la última fecha de modificación del archivo. Como tiene esa directiva ExpiresDefault, también enviará el encabezado Expires con un tiempo igual al tiempo de modificación del archivo (9:53) más dos horas. Así que aquí es parte de lo que ve el navegador:

Last-Modified: Wed, 18 Feb 2009 09:53:00 GMT 
Expires: Wed, 18 Feb 2009 11:53:00 GMT 

Si el tiempo en el que el navegador hace que esta solicitud es antes de 11:53 GMT, el navegador va a almacenar en caché la página, ya que aún no ha expirado.Entonces, si el usuario visita por primera vez la página a las 11:00 GMT y luego vuelve a la misma página a las 11:30 GMT, el navegador verá que su versión almacenada en caché sigue siendo válida y no (o, mejor dicho, está permitida).) hacer una nueva solicitud HTTP.

Si el usuario va a la página una tercera vez a las 12:00 GMT, el navegador ve que su versión almacenada en caché ha expirado (es después de 11:53) por lo que intenta validar la página, enviando una solicitud al servidor con un encabezado If-Modified-Since. Se devolverá una respuesta 304 (no modificada) sin cuerpo ya que la fecha de la página no se ha modificado desde la primera vez que se atendió. Dado que la fecha de caducidad ha pasado, la página está "obsoleta", se realizará una solicitud de validación cada vez que se visite la página hasta que falle la validación.

Ahora, imaginemos que ha cargado una nueva versión de la página a las 11:57. En este caso, el intento del navegador para validar la versión antigua de la página a las 12:00 falla y lo que recibe en la respuesta, junto con la nueva página, estas dos nuevas cabeceras:

Last-Modified: Wed, 18 Feb 2009 11:57:00 GMT 
Expires: Wed, 18 Feb 2009 13:57:00 GMT 

(La última fecha de modificación del archivo se convierte en 11:57 al cargar la nueva versión, y Apache calcula el tiempo de caducidad como 11:57 + 2:00 = 13:57 GMT).

La validación (utilizando la fecha más reciente) no será requerido ahora hasta las 13:57.

(Nota por supuesto que muchas otras cosas se envían junto con las dos cabeceras que se enumeran más arriba, sólo recorta lado todo lo demás para simplificar)

+0

Hola David, esto tiene sentido, aunque todavía no estoy seguro, por qué y cómo sabe el servidor enviar el navegador. Entonces, si entiendo correcto, la próxima vez que el navegador solicite el recurso, el servidor de alguna manera envía información al navegador sobre el estado de modificación de los archivos, pero ¿no es esto un get –

+0

? Pensé que esto sería más fácil de explicar con un ejemplo, entonces Edité uno en ... –

+0

gracias increíble por su tiempo –

0

Mi comprensión es que la modificación le pide al navegador que base el tiempo de caché en función del valor del encabezado HTTP Last-Modificatied. Entonces, la modificación más 2 horas sería el tiempo de Última Modificación + 2 horas.

3

El servidor envía un encabezado como: "Last-Modified: Wed, 18 Feb 2009 00:00:00 GMT". La memoria caché se comporta en función de este encabezado o del tiempo de acceso.

Digamos que si se espera que el contenido se actualice todos los días, quiere que caduque "modificación más 24 horas".

Si no sabe cuándo se actualizará el contenido, entonces es mejor basarlo en el tiempo de acceso.

+0

Hola Andrew, gracias por tu respuesta. ¿Cuándo y con qué frecuencia el servidor envía el encabezado Last Modified? o sucede durante una sesión del navegador –

0

En primer lugar, gracias a David Z para la explicación detallada anterior . En respuesta a la pregunta de bosquimano sobre por qué tiene sentido invocar el almacenamiento en caché si el servidor todavía está obligado a realizar una solicitud, la respuesta es que el tiempo se guarda en lo que devuelve el servidor. Si las directivas de caché indican que el contenido de un archivo aún está actualizado, en lugar de devolver el contenido, se devuelve un código 304 con un cuerpo de respuesta vacío. Ahí es donde se guarda el tiempo.

Una mejor explicación de lo que he dado es aquí, desde https://devcenter.heroku.com/articles/increasing-application-performance-with-http-cache-headers:

A pesar de las peticiones condicionales hacen invocar una llamada a través de la red, los recursos no modificados como resultado un cuerpo de la respuesta vacío - ahorrando el costo de la transferencia de la recurso de regreso al cliente final. El servicio de backend a menudo también puede determinar muy rápidamente la última fecha de modificación de un recurso sin acceder al recurso, que a su vez ahorra un tiempo de procesamiento no trivial.

-basada Tiempo Una solicitud condicional basada en el tiempo asegura que sólo si el recurso solicitado ha cambiado desde que se copia en caché del navegador se transferirán los contenidos. Si la copia en caché es la más actualizada, el servidor devuelve el código de respuesta 304.

Para habilitar las solicitudes condicionales, la aplicación especifica la última hora modificada de un recurso mediante el encabezado de respuesta Last-Modified.

Cache-Control: público, max-age = 31536000 -la última actualización: Lunes, 03 Jan 2011 17:45:57 GMT

La próxima vez que el navegador solicita este recurso sólo se le preguntará por los contenidos del recurso si están sin cambios desde esta fecha con el If-Modified-Since encabezado de solicitud

If-Modified-Since: Mon, 03 Jan 2011 17:45:57 GMT

Si el recurso hasn' t cambiado desde el lunes, 03 de enero de 2011 17:45:57 GMT el servidor volverá con un cuerpo vacío con el código de respuesta 304.

Cuestiones relacionadas