¿Cómo puedo obtener el control del comportamiento de caché de Google App Engine en WebKit (etags enloquecidos)?

Question

Situación: correr un sitio de Google App Engine con default_expiration de mi contenido estático establecido en "14d"

Problema: en Chrome y Safari, visitando una URL (no recarga, sólo poner el cursor en el barra de direcciones y presionar Enter), provoca que se disparen un montón de solicitudes con los encabezados If-None-Match. Las respuestas son siempre 304 No modificadas, como se esperaba. Puedo ver cómo se desencadenan estas solicitudes en un proxy de depuración como Charles o Fiddler.

Deseo: para evitar estas solicitudes y 304 respuestas enteramente para contenido estático: simplemente confíe en el contenido en caché del navegador cuando esté disponible.

Usamos el estándar "contenido estático de caché durante mucho tiempo, nos encargamos de agregar las modificaciones de la versión = {versión} a nuestras cadenas de consulta cuando necesitamos destruir el sistema de caché", así que Realmente me gusta evitar los 304.

Creencia: Creo que esto es causado por el encabezado etag que el motor de aplicación envía hacia abajo con cada respuesta de contenido estático. El SDK del motor de la aplicación no no envía este encabezado hacia abajo, y no veo este comportamiento 304 al jugar con el SDK.

Algún consejo? ¿Puedes desactivar etags para el contenido estático del motor de la aplicación?

Actualizado con un ejemplo pieza de contenido estático:http://www.khanacademy.org/stylesheets/shared-package/compressed.css

Answer 1

Aunque no creo que haya ninguna forma de controlar el comportamiento del encabezado etags para GAE, esto es causado por un error en WebKit que hace que todo el contenido estático se vuelva a descargar cuando se recibe un redireccionamiento 302 después de un POST solicitud.

Una vez que WebKit corrige este error, el problema debería desaparecer.

Si es necesario, puede solucionar temporalmente este error de redireccionamiento-POST específico redirigiendo a través de un encabezado Refresh en lugar de utilizar un redireccionamiento 302.

https://bugs.webkit.org/show_bug.cgi?id=38690

WebKit image reload on Post/Redirect/Get

http://www.google.com/support/forum/p/Chrome/thread?tid=72bf3773f7e66d68&hl=en

Answer 2

Chrome 9.0, Windows. Al cargar su página de inicio, default.css, así como todos los demás archivos .css se sirven desde la memoria caché, sin realizar una solicitud. Creo que este es un comportamiento específico del navegador, también debe consultar otros navegadores.

Además, revise estas instrucciones de Google, que me ayudó mucho cuando params sintonía de almacenamiento en caché: http://code.google.com/speed/page-speed/docs/caching.html

Answer 3

Dado que este es un problema con Chrome y Safari, podría utilizar HTML5 App Cache para evitar llamadas de servidor en recursos estáticos por completo. Vea un ejemplo here.

Answer 4

Trate de ver si sucede lo mismo cuando no presiona "enter" o refresh, sino simplemente siga un enlace. Su navegador hace algo diferente en esos casos. Safari solo hace las solicitudes de la forma en que se supone que deben hacerse si no utiliza la actualización o solicita nuevamente la página explícitamente.

Puede probar esto de manera muy sencilla en un Mac. Ejecutar un servidor sencillo con netcat (nc) en algún puerto, digamos 9090:

nc -l 9090 

crear una página simple con un enlace a http://localhost:9090 en él, haga clic en él, y ver los encabezados de las pantallas de mando NC.

regresar manualmente una respuesta, escribiendo en nc, por ejemplo, algo como

HTTP/1.0 200 OK 
ETag: "xyz" 
Content-type: text/plain 

Some text. 

Haga clic en el enlace nuevamente y vea el encabezado If-None-Match en la solicitud.Haga una devolución después de la dirección en la barra de direcciones, y verá que Safari no envía el encabezado.

Answer 5

Debe eliminar los encabezados Last-Modified y ETag.

Al eliminar el encabezado ETag, deshabilita las cachés y los navegadores para que no puedan validar archivos, por lo que se ven obligados a confiar en el encabezado Cache-Control y Expires. Las etiquetas de entidad (ETags) son un mecanismo para buscar una versión más reciente de un archivo en caché.

Al eliminar los encabezados Last-Modified y ETag, eliminará totalmente las solicitudes If-Modified-Since y If-None-Match y sus 304 respuestas no modificadas, por lo que un archivo permanecerá almacenado en caché sin buscar actualizaciones hasta que caduque el encabezado indica que hay nuevo contenido disponible.

Más información aquí: http://www.samaxes.com/2008/04/htaccess-gzip-and-cache-your-site-for-faster-loading-and-bandwidth-saving/.

Lamentablemente no sé cómo puede desactivarlos para el contenido estático de GAE.

Answer 6

Su valor ETag está bien. ETag no fuerza la revalidación. Simplemente permite que sea más confiable que la fecha de la última modificación. Acabo de navegar a su ejemplo de contenido estático usando Chrome 9, y su contenido se almacena en caché y no se revalida innecesariamente. El problema que vio podría estar relacionado con la configuración del navegador "siempre volver a validar", que no es la predeterminada para la mayoría de los navegadores. También podría ser un error relacionado con Mac webkit.

Answer 7

he publicado un nuevo número para solicitar esta función por la configuración appengine-web.xml.

¡Por favor revise y vota por ello!

https://code.google.com/p/googleappengine/issues/detail?id=10339&sort=-id&colspec=ID%20Type%20Component%20Status%20Stars%20Summary%20Language%20Priority%20Owner%20Log