ojo esternón y otros más:::
session_cache_limiter y session_cache_expire tienen que ver directamente con el recolector de basura de PHP (que funciona como debería ser a excepción del recolector de ASP y del de Java que realmente da pena), nada tiene que ver con el cliente!
Limpiar la caché es un poco difícil (metodología "what has been seen can't be unseen"), pero existen así a la rápida 3 métodos para
evitar que se crea una caché, y a excepción de una, TODAS involucran cabeceras
1.- Método más fácil: la caché se guía principalmente por la URL, por lo tanto, cambiando la URL el webserver debería devolver un código 200 en vez del 304. Esto es tan fácil como hacer:
pagina.asp?i=11111
y en el siguiente request:
pagina.asp?i=11112
Es por este método que en PHP solía existir el SID, que básicamente era la ID de la sesión. Obviamente, después se reemplazó por algo más powa, pq este sistema era muy engorroso.
2.- Métodos más a prueba de fallos:
Controlando las cabeceras, se puede evitar la creación de una caché. El primero es ir verificando por el ETag. Sin embargo, creo que ASP
no tiene soporte para esto. Esto fue una iniciativa de Apache, por lo que no me extrañaría que IE tampoco tuviera soporte para esto
Los demás navegadores cuentan todos con soporte para ETags.
El segundo método que se me ocurre es enviar esto a las cabeceras: (de nuevo en PHP que es lo que manejo):
Código PHP:
header('Expires: Tue, 03 Jul 2001 06:00:00 GMT');
header('Last-Modified: '.gmdate("D, d M Y H:i:s").' GMT');
header('Cache-Control: no-store, no-cache, must-revalidate');
header('Cache-Control: post-check=0, pre-check=0', false);
header('Pragma: no-cache');
Si no se colocan todas esas, van a tener problemas con IE5, IE6, IE7 y por último IE8. (En firefox basta con Expires o Cache-Control, tal como recomienda
el RFC de las cabeceras, lectura MÁS que recomendado para trabajar con la caché
). IE5 por ejemplo sólo soporta Pragma.
El otro pajarito complicado es Opera, ese navegador cachea tanto que cuesta hacer las reglas para que no lo haga
El tercer método via cabeceras consiste en revisar si acaso vienen las cabeceras de IF_MODIFIED_SINCE y/o HTTP_IF_MODIFIED_SINCE y controlar mediante estos si mandar un 200 OK o un 304 Not Modified, aunque este último método (junto con el de ETags) sólo lo recomiendo en caso de archivos estáticos, tales como CSS, JS e imágenes. Para propósitos generales de scripts, recomiendo el segundo método.
@Ribosoma: caché o no caché es una configuración del webserver (bueno, tb del cliente), el cliente simplemente pide al servidor que se le sirva un documento X el cual tiene fecha de vencimiento de la caché Y. El webserver revisa si Y del cliente es igual al Y que tiene él y si es el mismo, manda un código 304 que el documento NO se ha modificado y el cliente traerá la página desde la caché. En el caso que el servidor tiene una versión más actual, le envía el código 200 y en seguida el documento en su conjunto. Ahora bien, todo cambia cuando se envían cabeceras adicionales, ya que algunas de las cabeceras arriba expuestas le dicen al navegador que NO puede guardar en caché con lo cual no envía las cabeceras adicionales que contiene el campo Y.
Por último, si es primera vez que se recibe X, el navegador no puede mandar ninguna fecha Y debido a que nunca antes lo ha tenido. En ese caso, el Y del navegador (null) será distinto a la fecha Y que tiene el servidor y devuelve un 200.
Lee el documento que dejé más arriba que explica todo el proceso que ocurre entre el user-agent y el webserver, te aclarará bastante la película
Es largo y difícil de entender, pero yo toi listo para escribir un navegador desde cero
Saludos !!
LinkBack URL
About LinkBacks
Citar
Iniciado por narcosatanico 
)
