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.
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.
Miguel Angel Alvarez
Fundador de DesarrolloWeb.com y la plataforma de formación online EscuelaIT. Com...