Trabajo con el buffer de la página

  • Por
Vemos en que casos se guarda la página en un buffer al procesarla y la utilidad de trabajar con el buffer con ejemplos prácticos.
Las páginas ASP se construyen primero en un buffer del servidor y más tarde se mandan al cliente. Esta es la configuración predeterminada de ASP 3.0, aunque no era así en las versiones anteriores. Esto quiere decir que el código HTML que va generando el servidor al procesar la página ASP, se va guardando en una memoria intermedia hasta que se termina de procesar, momento en el que el servidor se encarga de mandar el contenido del buffer.

Nota: parece que será importante saber en que versión de ASP estamos trabajando. Los IIS 4.0 tienen instalado ASP 2.0 por defecto y los IIS 5.0 tienen ASP 3.0.

Nosotros podemos en cierta medida controlar el envío de la página al cliente para que este se realice en los momentos que nosotros deseamos. Para ello tenemos unos cuantos métodos y propiedades del objeto response a nuestra disposición.

Response.Buffer es una propiedad que si está a true (la opción por defecto en ASP 3.0) indica al servidor que debe utilizar el buffer. Si está a false (opción por defecto para versiones anteriores de ASP) no lo utiliza.
Response.Flush método para ordenar al servidor que mande lo que tenga en el buffer al cliente.
Response.Clear método que limpia el buffer, lo vacía y se pierde su contenido. Solo es útil si se está utilizando el buffer
Response.End método que detiene la ejecución de la página, la termina.

Algunas utilidades

Con la propiedad buffer y los métodos anteriores podremos implementar funcionalidades varias. Por ejemplo, si una página está compuesta por grandes bloques de procesamiento en los que utiliza bastante tiempo podemos, entre bloque y bloque mandar al cliente los datos que se hayan escrito ya.

<%
'Código de la página lento de procesar
...
Response.Flush 'envío lo escrito hasta ahora

'Otro trozo de código de la página lento de procesar
...
Response.Flush 'envío lo escrito hasta ahora
...
%>


Trabajo con encabezados y texto

También podemos con estas herramientas evitar algún error derivado de escribir en los encabezados del HTTP después de haber escrito en la página texto o HTML. Recordemos las cookies, se dijo cuando se comentaban que viajan en los encabezados del HTTP y que éstos se mandan al cliente antes que el texto con el código de la página. Por esta razón, todo el trabajo con las cookies se ha de realizar antes de escribir ningún texto en la página. Es parecido a lo que pasa con el objeto método redirect del objeto response. En el ejemplo siguiente vamos a ver un ejemplo para ilustrar este asunto.

Se trata de escribir mucho texto en la página y luego tratar de leer una cookie del cliente. Debería dar un error, pero depende de que la página esté o no en el buffer, pues si está en el buffer no se ha mandado y por lo tanto no hemos escrito ningún texto en el cliente. Como hemos dicho que se mande o no se mande depende de la propiedad response.buffer.

Este ejemplo, con response.buffer en true, funciona perfectamente porque, aunque ya hemos escrito cosas en la página, no las hemos mandado a el cliente, porque están en el buffer. Esta es la opción predeterminada en ASP 3.0. Se puede ver el ejemplo en ejecución en esta página.

<%
response.buffer = true
for i=0 to 1000
   response.write "Taller de ASP de desarrolloweb.com "
next
response.clear
response.cookies ("ppepe") = "pqpqpqpqpqpqpqpqpq"
response.write request.cookies ("ppepe")
%>


Con response.buffer a false el mismo script va a dar un error porque no se pueden leer o escribir cookies si ya hemos escrito algo en la página y se ha mandado al cliente. False es la opción predeterminada en ASP 2.0 y 1.0. Se puede ver el ejemplo en ejecución en esta página.

<%
response.buffer = false
for i=0 to 1000
   response.write "Taller de ASP de desarrolloweb.com "
next
response.cookies ("ppepe") = "pqpqpqpqpqpqpqpqpq"
response.write request.cookies ("ppepe")
%>


Salirse si el usuario se ha ido

Otro ejemplo interesante para ilustrar lo que se puede hacer controlando los flujos es detenerlos en el caso de que el cliente abandone la página. Imaginar que tenemos un proceso que requiere mucho procesamiento y el cliente se va de la página antes de acabarlo. Para evitar todo ese tiempo perdido en el procesamiento de su solicitud se puede ir comprobando a medida que va pasando el tiempo si el cliente continúa a la espera, pues si no continúa será inútil terminar el procesamiento que estábamos realizando.

Para conseguir saber si el cliente continúa a la espera se puede utilizar una propiedad del objeto response llamada IsClientConnected que devuelve true en caso de que el cliente siga a la espera y false en caso contrario. El ejemplo siguiente acabará de aclararlo todo.

<%
' Procesamiento muy largo en el tiempo
...
if not Response.IsClientConnected then
   Response.End
end if
...
' Procesamiento muy largo
%>


Es interesante destacar que la propiedad Response.IsClientConnected no se puede utilizar con seguridad hasta ASP 3.0. En ASP 2.0 fue implementada, aunque no es aconsejable usarla porque tenía algún problema para dar resultados correctos.

Autor

Miguel Angel Alvarez

Miguel es fundador de DesarrolloWeb.com y la plataforma de formación online EscuelaIT. Comenzó en el mundo del desarrollo web en el año 1997, transformando su hobby en su trabajo.

Compartir

Comentarios

kike_86

20/7/2011
Error de sintaxis.
Puede ser tonto, pero así como está la siguiente línea:

"Como hemos dicho que se mande o no se mande depende de la propiedad response.buffer"

puede prestarse a malentendidos (a mí me pasó). Así que si es posible sólo agreguen la coma:

"Como hemos dicho, que se mande o no se mande depende de la propiedad response.buffer "

Saludos.