2010-09-23 19 views
7

Me gustaría que una respuesta HTTP caduque dentro de 24 horas (lo que significa que el navegador no realizará ninguna solicitud para esa URL hasta mañana). Pero, si la solicitud vuelve a emitirse mañana después del vencimiento, quiero asegurarme de que el navegador envíe los encabezados de solicitud correctos para que el servidor envíe un 304 en lugar de forzar al cliente a volver a descargar todo el cuerpo de respuesta si no lo ha hecho. No cambió en el servidor. Y me gustaría que ese 304 expire también 24 horas después.correctos encabezados de respuesta HTTP para causar 304s después de la expiración del contenido

En primer lugar, ¿es posible este sccenario? ¿O tengo que elegir entre el caché de estilo de caducidad y el caché de estilo 304, pero no ambos? Si es posible, ¿cuáles son los encabezados de respuesta correctos (tanto para la respuesta inicial como para los siguientes 304) que harán que suceda?

Si sucede tan a menudo, la respuesta varía según el tipo de navegador/versión, a continuación, qué encabezados funcionan para qué navegadores, y qué navegadores no podrán hacer lo que quiero en absoluto? Solo me interesan los navegadores más comunes actualmente en uso (por ejemplo, IE6 +, FF3 +, Chrome más reciente, Safari más reciente).

Disculpas si esta respuesta ya se ha solicitado en SO-- He buscado durante un tiempo y aparece en blanco.

CLARIFICACION: estoy haciendo esta pregunta porque yo estoy armando un conjunto de pruebas automatizado para verificar, independientemente de la plataforma del servidor, una aplicación web que está generando las cabeceras HTTP correctos para generar el comportamiento de los clientes de almacenamiento en caché que queremos que todas nuestras aplicaciones web tengan. Así que no estoy interesado (al menos por ahora) en cómo configurar Apache/IIS/PHP/Rails/Django/JSP/ASP.NET/etc. para generar los encabezados correctos. Simplemente quiero saber, solo en la capa HTTP, cuáles son los encabezados correctos.

ACTUALIZACIÓN: Encontré this SO question que responde a una parte de mi pregunta. De acuerdo con RFC 2616 10.3.5, dice que debería incluir un encabezado Expires: o Cache-Control: max-age en los 304 devueltos por el servidor. Este es definitivamente el comportamiento deseado.

Lo que esa pregunta no responde, sin embargo, es si este enfoque compatible con RFC funcionará en navegadores populares existentes, especialmente IE6/7/8 que son los culpables habituales de cumplimiento de normas, pero también IE9, FF4 +, más reciente Chrome y el último Safari que nuestra aplicación también debe admitir. Si alguno de esos navegadores no se comporta como los mandatos de RFC, ¿hay soluciones alternativas que pueda utilizar?

+0

Sin saber a qué servidor web pertenece esto y si el contenido es generado por código o simplemente un archivo estático servido por el servidor es imposible de responder. – symcbean

+0

En este caso, seguramente serán solicitudes dinámicas, pero mi pregunta es independiente de la plataforma del servidor. Solo estoy buscando los encabezados de respuesta HTTP deseados para hacer que los clientes guarden en caché como me gustaría. Agregué una aclaración al final de mi pregunta para elaborar. –

Respuesta

5

Envíe un encabezado ETAG para que el cliente pueda realizar una solicitud HTTP condicional para revalidar una respuesta después de que haya expirado su período de vigencia de la renovación.

Envía una directiva Cache-Control: max-age o Expires para especificar cuándo quieres que caduque el recurso.

Evite utilizar un encabezado Vary o cualquier directiva que prohíba el almacenamiento en caché.

Estas directivas funcionarán en todos los navegadores populares (IE6 +, Firefox, Chrome) a excepción de Safari en Windows, que solo carece de una caché HTTP persistente que funciona en varias sesiones.

http://blogs.msdn.com/b/ie/archive/2010/07/14/caching-improvements-in-internet-explorer-9.aspx explica qué sucede cuando no se proporcionan los encabezados de almacenamiento en caché adecuados.

El inspector de respuesta de caché de Fiddler le ayudará a comprender cómo se almacenará en caché una respuesta determinada.

0

Recomiendo usar the ETag header.

+1

ETag solo no es suficiente, ya que los clientes seguirán haciendo una nueva solicitud HTTP cada vez para comprobar si ETag todavía está vigente. Se necesita al menos un encabezado adicional para controlar la caducidad del contenido a fin de evitar hacer solicitudes durante 24 horas antes de volver a consultar para un nuevo ETag. –

+0

Muy útil, gracias Justin! Así que supongo que necesitarías usar el encabezado 'Expires' junto con' ETag', ¿verdad? –

+0

No estoy seguro de si Expires plus ETag hará el truco (y aunque lo haga funcionará en varios navegadores). –

Cuestiones relacionadas