memcache - ¿Cómo puedo controlar el comportamiento de caché de Google App Engine en WebKit(etags enloquecidos)?
google cloud memcache (7)
Situación: ejecutar un sitio de Google App Engine con el valor predeterminado de expiración de mi contenido estático en "14d"
Problema: en Chrome y Safari, visitar una URL ( no volver a cargar, simplemente colocar el cursor en la barra de direcciones y pulsar Enter) hace 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: evitar estas solicitudes y 304 respuestas completamente para contenido estático; simplemente confíe en el contenido almacenado en caché del navegador cuando esté disponible.
Usamos el "contenido estático de la memoria caché estándar" 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é, por lo que realmente queremos evitar los 304.
Creencia: Creo que esto es causado por el encabezado etag que el motor de la aplicación envía con cada respuesta de contenido estático. El SDK del motor de la aplicación 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 de contenido estático: http://www.khanacademy.org/stylesheets/shared-package/compressed.css
Aunque no creo que haya ninguna forma de controlar el comportamiento del encabezado etags para GAE, esto se debe a un error en WebKit que hace que todo el contenido estático se vuelva a descargar al recibir un redireccionamiento 302 después de una solicitud POST .
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 usar un redireccionamiento 302.
https://bugs.webkit.org/show_bug.cgi?id=38690
Recarga de imagen de WebKit en Publicar / Redirigir / Obtener
http://www.google.com/support/forum/p/Chrome/thread?tid=72bf3773f7e66d68&hl=en
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, consulte estas instrucciones de Google, me ayudaron mucho al ajustar los parámetros de almacenamiento en caché: http://code.google.com/speed/page-speed/docs/caching.html
Debe eliminar los encabezados Last-Modified y ETag.
Al eliminar el encabezado ETag, inhabilitas las cachés y los navegadores para que no puedan validar los 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 nueva de un archivo almacenado en caché.
Al eliminar el encabezado 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 el encabezado Expires indique contenido nuevo está disponible.
Más información aquí: http://www.samaxes.com/2008/04/htaccess-gzip-and-cache-your-site-for-faster-loading-and-bandwidth-saving/ .
Desafortunadamente no sé cómo puedes desactivarlos para el contenido estático de GAE.
Debido a que este es un problema con Chrome y Safari, puede usar HTML5 App Cache para evitar completamente las llamadas al servidor en recursos estáticos. Mira un ejemplo here .
Intente ver si sucede lo mismo cuando no presiona "enter" o refresh, sino que simplemente sigue 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.
Puedes probar esto muy simplemente en una Mac. Ejecute un servidor simple con netcat (nc) en algún puerto, digamos 9090:
nc -l 9090
Cree una página simple con un enlace a http: // localhost: 9090 en ella, haga clic en ella y observe los encabezados que muestra su comando nc.
Devuelve manualmente una respuesta escribiéndola en nc, por ejemplo, algo así 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.
Publiqué un nuevo problema para solicitar esta función mediante la configuración de appengine-web.xml.
Por favor verifique y vote por ello!
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 viste 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.