páginas caducas al volver atrás...

Las páginas que son invocadas por POST, deben ser recargadas al volver atrás
para actualizar la información y mantener la integridad de los datos. Así se
estable en una recomendación de IETF y tanto Microsoft como otros
desarrolladores entre los que se encuentra Mozilla la acatan. El problema
con MSIE es que está horriblemente implementado con esa pantalla blanca
avisando que la página caducó. Mozilla lo hace mejor a través de un popup.

De acuerdo a las especificaciones de HTTP 1.1 las solicitudes mediante POST
no deben ser almacenadas en cache, ni tampoco pueden estar asociadas a una
URI para ser llamadas directamente. Por ello, el navegador justamente envía
el mensaje de recarga (la página no está en caché ni tiene una URi asociada
para ser llamada directamente). Ahora, una aproximación a la solución:

Si estás usando un lenguaje de servidor como PHP o ASP, se deben ajustar las
cabeceras o headers que se envían al navegador. No sirve de nada utilizar la
etiqueta <meta> para este propósito (particularmente en MSIE) pues es
interpretada después de que se envió todo el flujo por HTTP.

Los headers que controlan esto son:

header("Expires: " . gmdate("D, d M Y H:i:s", time() + 17000) . " GMT" );
header("Last-Modified: " . gmdate("D, d M Y H:i:s", time() - 21575) . "
GMT" );
// HTTP/1.1
header("Cache-Control: no-store, no-cache, must-revalidate");
header("Cache-Control: post-check=0, pre-check=0", false);
// HTTP/1.0
header("Pragma: no-cache");

Están hechas para PHP. Esta es la configuración que asegura que el navegador
siempre recargue en caso de solicitudes POST. Se deben ajustar de manera
diferente para evitar el consabido mensaje de racarga forzando que la página
sí se almacene en el cache del cliente, tartea de tu programador. Pero una
advertencia: Cuando se evita la recarga forzada de la página, la información
enviada a bases de datos con POST, y la información almacenada en sesiones
NO COINCIDIRÁ con lo que el usuario vea en pantalla; esto es, estará viendo
información previa al envío de datos. Estó provocará que si el usuario graba
de nueco, le información antigua remmplazará a la información nueva. Por eso
es importante la recarga y la recomendación para usarla.

Lo más sano, es que una vez grabado en la base de datos se utilice el header
"Location" para que el contenido se refresque y se evite totalmente el
reenvío de información vía POST.

Un saludo

Miguel Angel Da Vila





"Luciano A. Ferrer" escribió en el mensaje
news:

Hola!

Nuestro programador anda lidiando con las páginas caducas al volver
atrás...
Son una serie de formularios seguidos, que pasan los datos mediante
POST...
Se le ha quemado el libro y la cabeza, así que lo ha puesto mediante GET
y el problema no está...

Pero alguien sabe de alguna forma mejor de solucionar este problema?

Se me había ocurrido que los datos podrían ser leidos desde un lugar
donde previamente los habíamos guardado... pero siempre hay que hacer
una página (puente) que procesa y guarda los datos, y entonces si
vuelven 2 veces (o 4 o 6 u 8...) seguirá apreciendo un mensaje de página
caduca...

Alguna idea?

Saludos y mil gracias a todos!
-
Saludos!
Luciano A. Ferrer @work