Programación Web

Proporcionando dinamismo a la Red

Autor:

Hadi Hariri
Hadi@delphihome.com

Prohibida la reproducción total o parcial sin permiso explícito del autor.

 Programación Web - Proporcionando dinamismo a la red
Con el continuo crecimiento de la red Internet, cada vez más las empresas de informática solicitan
profesionales con experiencia en la programación de aplicaciones Web. Con esta serie de artículos se
pretende proporcionar los conocimientos necesarios para pode r abordar problemas de distinta
complejidad.

Terminología
En este primer artículo, voy a dar una introducción a la tecnología utilizada en la programación de
aplicaciones Web, tanto a escala general como al nivel de Delphi. Si llevas tiempo en el mundo de
Internet, seguramente habrás oído hablar de los términos CGI, ISAPI o NSAPI. Muchas personas
confunden estos con aplicaciones propiamente dichas. Sin embargo, se trata de especificaciones.
Inicialmente surgió el protocolo CGI (Common Gateway Interface, Interfaz de pasarela común) y aunque
parezca un nombre extraño, tiene su sentido. “Interfaz” indica unas normas de intercambio de
información entre aplicaciones, en este caso, entre un servidor Web y una aplicación externa, destino de
una solicitud HTTP. “Pasarela” viene a referirse a que pocas aplicaciones realizan un procesamiento
directo, actuando como pasarelas de acceso a otras aplicaciones que no ofrecen soporte para la Web.
“Común” indica que se trata de una especificación independiente de la plataforma y del sistema
operativo.
Como era de esperar, Microsoft y otras empresas no tardaron mucho en sacar sus propias
especificaciones. De ahí que surja ISAPI (Internet Server API) de la mano de Microsoft y NSAPI de
Netscape Corporation (actualmente desapareciendo del mapa). La gran ventaja de ISAPI/NSAPI sobre
CGI es que el primero trabaja sobre librerías de vínculo dinámico. Esto trae consigo ventajas y algunos
inconvenientes. La primera y mayor ventaja es que al tratarse de una DLL, solamente se carga una vez en
memoria permaneciendo ahí hasta que apaguemos la máquina o el servidor Web. Los CGI se
implementan mayormente como ejecutables (o interpretados) y como tales, cada petición requiere que se
cargue el código en memoria, se procese la petición y se descargue. Como se puede ver, esto aumenta el
tiempo de respuesta y disminuye la eficiencia.
Antes de pasar al siguiente apartado, quiero hacer una aclaración. Hay que distinguir entre lo que es el
servidor Web, una aplicación (o extensión) Web y un filtro ISAPI. El primero es el software que
utilizamos para proporcionar presencia en la World Wide Web (por ejemplo, Internet Information Server
de Microsoft, Netscape Enterprise Server de Netscape Corporation o Apache). El segundo es una
aplicación. Estas aplicaciones se llaman mediante peticiones directas a ellas y dan como resultado una
salida. El tercero es un filtro ISAPI, y es exactamente eso, un filtro. Se encuentra entre nuestro Servidor
Web y las peticiones HTTP, pudiendo ser las peticiones llamadas directas a una aplicación o a cualquier
otro recurso que este disponible en nuestro servidor. El filtro actúa sobre las peticiones y permite cambiar
el resultado esperado, hacer redirecciones, etc. La diferencia principal con respecto a una aplicación es
que no es necesario hacer una llamada directa a ella para activarla.

El WebBroker de Delphi
Si dispones de la versión Cliente/Servidor (o Profesional a partir de Delphi 5), puedes utilizar la
tecnología WebBroker para programar aplicaciones de red con bastante facilidad. Aunque realmente
podría hacerlo también con la versión
estándar de Delphi, el WebBroker facilita
muchas de las tareas. Delphi nos permite
crear aplicaciones utilizando la
especificación CGI, ISAPI/NSAPI o Win-
CGI. Las diferencias fundamentales entre
CGI’s e ISAPI/NSAPI ya se han
mencionado anteriormente. Win-CGI es
otra especificación que en vez de utilizar la
entrada y salida estándares, usa unos
ficheros INI para leer los valores de una
petición y escribir los resultados. En este
artículo, vamos a hacer programas
Figura 1 utilizando ISAPI, aunque casi todo lo que

1
 Programación Web - Proporcionando dinamismo a la red
se explique se puede aplicar igualmente a los CGI.
Para iniciar un nuevo proyecto ISAPI en Delphi, del menú File, seleccionamos New y después Web
Server Application. Delphi nos presenta el cuadro de diálogos de la Figura 1.
Dejamos marcado la opción por defecto y pinchamos el botón OK. Inmediatamente Delphi crea un
objeto TWebModule. Esta es la base sobre la que vamos a construir todas las aplicaciones que hagamos.
Puede verse que se parece a un TDataModule, y es que realmente de eso se trata. Un TWebModule no es
más que un TDataModule que incluye un TWebDispatcher. Ya tenemos unos cuantos nuevos términos
con los que trabajar. Veamos lo que es cada cosa.
En una aplicación normal utilizamos el TDataModule normalmente para compartir componentes no
visuales, como pueden ser componentes de acceso a datos. En una aplicación Web no existe ningún
componente visual, ni formularios (Forms) que puedan interactuar con el usuario. Todo lo que nos haga
falta para hacer la aplicación tiene que estar contenido en el TWebModule. Como ya he indicado, el
TWebModule es un TDataModule más un TWebDispatcher. Pues bien, ¿qué es el TWebDispatcher? Se
podría decir que sin este componente, poco podríamos hacer. Cada petición HTTP que se hace a nuestra
aplicación es interpretada por el TWebDispatcher y éste lo convierte en un punto de entrada
(TWebAction) de nuestra librería de enlace dinámico. Más adelante veremos los TWebActions con detalle
ya que son el corazón de nuestras aplicaciones. Pero antes examinemos un poco más el TWebModule.
Cada vez que se realiza una petición HTTP, se crea una nueva instancia de nuestro TWebModule y por
tanto de todos los componentes que éste contiene. Sin embargo, si tenemos declarada una variable global,
cada petición va a compartir la misma variable. Esto es uno de los inconvenientes de ISAPI. Imagínese el
siguiente caso: tenemos una DLL que contiene una variable global denominada Nombre. A esta DLL se le
pueden realizar dos peticiones, una para establecer el valor de la variable y otra para leerla. Supongamos
que llega un usuario y realiza una petición para escribir el valor Juan a nuestra variable. Un segundo más
tarde el mismo usuario desea leer el valor que acaba de asignar. Pero en este pequeño instante de tiempo,
un segundo usuario también hace una petición de escritura y escribe Álvaro a la variable. El primer
usuario leerá el valor Álvaro. Es muy importante entender lo que esta pasando. La variable global es
común para todas las instancias de la DLL. ¿Quiere decir esto que no se puede utilizar variables globales
en una ISAPI? No. Aunque personalmente a mi no me gusta utilizar variables globales, hay formas en que
se pueden hacer uso de ellas de manera segura, como pueden ser mediante mecanismos de sincronización
(por ejemplo, secciones críticas).
Cuando se crea una nueva instancia del TWebModule, ésta permanece en memoria para que peticiones
posteriores sean más eficientes. Esto también trae consigo un inconveniente. La instancia se queda en
memoria tal como esta, y todos los componentes que contienen guardan los valores que tenían. Por ellos
es muy importante tener alguna función que inicialice todos los datos necesarios antes de una petición.
Este comportamiento se debe a que la propiedad CacheConnections del objeto TISAPIApplication por
defecto tiene el valor de verdadero. Se podría inicializar este valor a falso para evitar guardar instancias
utilizadas en memoria, lo que pasa es que bajaría el rendimiento y realmente se perdería parte de la
ventaja de trabajar con ISAPI en vez de CGI.

Eventos de una vez

Al igual que el TDataModule, el TWebModule dispone de los eventos OnCreate y OnDestroy.
Dependiendo del valor que se haya asignado a la propiedad CacheConnections, estos eventos pueden
dispararse o bien por cada petición que se haga o
solamente una vez. Por defecto, con esta propiedad a
False, el evento OnCreate se dispara la primera vez
que se realiza una petición a la DLL. El evento
OnDestroy se llama cuando se apaga el servidor Web
o cuando se descarga la DLL (en Internet Information
Server existe la posibilidad de ejecutar una aplicación
en su propio espacio de memoria y seleccionando
esta opción, podemos descargar la aplicación de
memoria).

Figura 2

2
 Programación Web -Proporcionando dinamismo a la red
Aparte de estos dos eventos, dispone de dos más que son OnBeforeDispatch y OnAfterDispatch. Cada vez
que se realiza una petición, antes de procesarse la petición en sí, se dispara el evento OnBeforeDispatch.
Esto nos brinda la oportunidad de realizar una serie de comprobaciones, por ejemplo, ver si la petición
que se solicita esta disponible, comprobar la existencia de Cookies, etc. Como se mencionó en el
aparatado anterior, las instancias del TWebModule que ya se han utilizado permanecen en memoria para
futuro uso tal como las dejó la última petición. Pues bien, podemos utilizar este evento para limpiar e
inicializar todos los datos necesarios.
De la misma forma que existe un evento antes de procesar un petición, como era de esperar, existe un
evento que se dispara después de la petición: OnAfterDispatch. Se podría de igual manera utilizar este
evento para comprobar lo que se devuelve en respuesta a la petición, aunque sinceramente les puedo decir
que en todo el tiempo que yo llevo programando aplicaciones Web, nunca he utilizado este método.

Programar sin estado

Una de las características más destacadas del protocolo HTTP es que es un protocolo sin estado. A la
hora de realizar aplicaciones, tenemos que tener esto en cuenta. Entre cada par de peticiones, nuestra
aplicación no guarda el estado anterior. Supongamos que realizamos la petición A, no podemos saber a
la hora de realizar una petición B si anteriormente se ha realizado la petición A. Esto influye también en
la forma en que hacemos aplicaciones Web. Tanto si estamos realizando un CGI o una ISAPI, no se debe
enfocar la programación orientada a eventos, a la que estamos acostumbrados en aplicaciones normales.
Debido a que no se guardan estados anteriores, no podemos saber si la respuesta a un evento se produce
por el mismo usuario o por otro usuario que haya hecho una nueva petición. Existen técnicas con las que
podríamos simular las transiciones entre estados, y veremos como realizarlo en artículos posteriores
(Cookies, URL “gordos” y campos HTML ocultos).

Preparar el entorno
En el siguiente número de la revista, cubriremos con más detalle los conceptos que se han explicado
aquí y escribiremos nuestra primera aplicación ISAPI. Para ello hace falta tener un Servidor Web
instalado en nuestra máquina y hacer unas cuantas preparaciones de antemano. Dependiendo de si tienen
Windows 95/98 o NT (o algún atrevido tiene Windows 2000), hay varias opciones a la hora de elegir el
servidor a instalar. El Personal Web Server de Microsoft es de distribución gratuita y viene tanto para
Windows 95/98 como para NT Workstation. Si dispone de NT Server puede utilizar el Internet
Information Server, de distribución gratuita también. Personalmente yo prefiero trabajar sobre NT
Workstation por varias razones. Aparte de proporcionar mayor estabilidad, uno de los errores más
frecuentes que se cometen a la hora de hacer aplicaciones Web es realizarlas en Windows 95/98 y luego
moverlas a NT. NT tiene mayor nivel de seguridad (tanto por el sistema de archivos NTFS, como a nivel
de servicios Web). Muchas veces la misma aplicación no funciona en NT y se debe precisamente a
restricciones de seguridad que no se tuvieron en cuenta a la hora del desarrollo. Os recomiendo que si vais
a hacer programación Web en serio, os planteéis cambiar a NT, para ahorraros disgustos a la larga.
Si hace la instalación por defecto del IIS (o PWS para NT), los directorios que se crearán serían:

C:\Inetpub\wwwroot
C:\Inetpub\scripts

En el primero se encuentran todos los documentos, imágenes y otros recursos que queráis publicar. En el
segundo es donde van a residir las aplicaciones que vamos a hacer. En el caso de NT, el primero debe
disponer de permiso de lectura para el usuario IUSR_NombreMaquina a nivel NTFS y el segundo debe
tener permiso de ejecución. En Windows 95/98 no hay que preocuparse por la seguridad.

Conclusión
En este primer artículo hemos visto una breve introducción a la tecnología Web y algunos conceptos de
Delphi relacionados con este tema. En el siguiente número comenzaremos la parte divertida: programar,
ampliando algunos conceptos vistos hasta ahora. Como siempre, antes de empezar a realizar cosas
nuevas, hay que coger un buen fundamento teórico. Es muy importante que comprenda bien esta
introducción antes de seguir.

3
 Programación Web- Proporcionando dinamismo a la red(II)
Hemos visto una introducción a la tecnología usada para realizar programas en Internet, y más
concretamente describimos algunas facilidades que Delphi nos aporta para poder realizar esta labor de
una manera sencilla. En esta entrega profundizaremos en los puntos ya mencionados y describiremos
otros mucho más interesantes desde el punto de vista práctico.
Como ya se comentó, Delphi permite realizar tres tipos de aplicaciones web: CGI, ISAPI y Win-CGI.
Nos centraremos principalmente en ISAPI, resaltando sus características más intersantes. Insisto en que
todo, o casi todo lo que se explica en el presente artículo y en posteriores, puede aplicarse de igual manera
a aplicaciones CGI , gracias a que los objetos que nos facilita delphi están diseñados para que podamos
trabajar de una manera muy transparente sin preocuparnos demasiado de si estamos programando una
ISAPI o un CGI aunque, como se verá, hay matices.
TWebActions
El corazón de todas las aplicaciones basadas en web reside en los TWebActions. El TWebDispatcher
convierte cada petición pasada a la URL en un punto de entrada de nuestra aplicación. Para acceder al
TWebActionItems, como otras propiedades similares, pinchamos en los puntos suspensivos que aparecen
en el inspector de objetos. Se nos presenta un editor de propiedades típica de la clase TCollection donde
podremos acceder individualmente a cada TWebActionItem. La tabla 1 muestra las propiedades de este
objeto.

Default Indica si se trata de la acción por defecto.

Enabled Indica si la acción esta habilitada o no.
MethodType El método permisible para llamar a esta acción.
Name Nombre de la acción
PathInfo El nombre que se pasará en la URL para llamar a la acción.
Producer El Producer asociado a la acción.

Dos de las propiedades son muy conocidas por todos dado que casi cualquier componente de Delphi las
tiene. En concreto se trata de la propiedad Name que indica el nombre que queremos dar a la acción y
Enabled que indica si la acción esta activada o no. Antes de seguir explicando el resto de propiedades ,
veamos como es una llamada típica a una aplicación.

http://www.direccion.com/scripts/aplicacion.dll/accion1?parametro1=valor1&parametro2=valor2

Se ha coloreado la URL para resaltar mejor cada parte. La primera es bien conocida por todos y se trata
únicamente de una dirección web. Detrás de ella viene el nombre (incluyendo la extensión) de nuestra
aplicación que en este caso se trata de una DLL. Lo que esta marcado en azul es lo más importante. La
palabra que empieza justo después de la última / y termina en el símbolo ? corresponde con la propiedad
PathInfo del TWebActionItem. Cada vez que se realiza una llamada a la aplicación, el TWebDispatcher
busca la acción cuyo PathInfo corresponda con el método solicitado desde la URL. Si no encuentra
ninguna, entonces mira a ver si existe una acción definida por defecto en nuestra DLL (Default := True) y
la procesa. Siguiendo con la descripción de la URL vemos como tras la acción, opcionalmente podemos
indicar parámetros que se pasan a la llamada cuando ésta se hace mediante un GET. El protocolo HTTP
soporta varios comandos, entre los que se encuentran GET, HEAD, POST y PUT. En Delphi, indicamos el
comando que la acción soporta mediante la propiedad MethodType. Ésta, además dispone de una quinta
opción que es mtAny, indicando que se acepta cualquiera de los comandos. En concreto, en el ejemplo
anterior vemos que se utiliza la URL para pasar parámetros a la llamada, siendo el formato
“nombre_parámetro” = “valor_parámetro” separando cada uno por el símbolo &. Entre los cuatro
comandos, describiré POST y GET ya que se trata de los más usuales. Por último, con la aparición de
Delphi 5, se ha añadido una nueva propiedad llamada Producer que examinaremos una vez que hayamos
visto los TPageProducers.

La solicitud
Cada vez que realizamos una solicitud al servidor, el cliente (navegador) manda un montón de
información. Esta información se engloba en el objeto TWebRequest en Delphi. Realmente no es el
mismo objeto sino un descendiente de él, que dependerá del tipo de aplicación que estemos realizando.

4
 Programación Web- Proporcionando dinamismo a la red(II)
En concreto, en Delphi existe el TISAPIRequest, TCGIRequest y el TWinCGIRequest. Invito al lector a
que revise las propiedades y métodos del TISAPIRequest, son muchos y aquí solamente vamos a cubrir
los más destacables. Entre las propiedades más interesantes, se encuentra el grupo asociado a la URL o
acción que se llama, siendo éstos el Host que contiene el nombre del servidor, ScriptName que indica el
nombre del fichero (o aplicación) al que estamos llamando, PathInfo corresponde a la acción y por último
Query que contiene los parámetros de la llamada, en caso de un GET. Se puede acceder a la composición
de todas estas propiedades mediante la URL. Otras dos propiedades bastantes interesantes son el Referer y
el RemoteAddr. La primera contiene la URL desde la cual se llamó a la aplicación, mientras que la
segunda contiene la dirección del cliente. ¿Puede imaginar todo lo que se puede hacer con estos datos? Mi
primera aplicación web consistía en realizar una auditoria de todas las páginas web de mi empresa.
Haciendo uso de las propiedades anteriores y unas cuantas más, como por ejemplo UserAgent que
contiene el navegador, era bastante fácil analizar cada petición y agrupar la información por dominio,
páginas, etc. Las propiedades del TWebRequest contienen la mayoría de la información que se pasa del
cliente al servidor en una petición HTTP. Sin embargo, si hay alguna cabecera adicional a la que se
necesita tener acceso y ésta no viene representada por una propiedad, se podrá obtener el valor utilizando
el método GetFieldByName.
Nos quedan dos cosas importantes por cubrir antes de pasar al siguiente apartado: QueryFields y
ContentFields. Como ya se vio anteriormente, tenemos la posibilidad de pasar parámetros en la URL
cuando hacemos la llamada. Esto se conoce como el método GET. Pues bien, desde Delphi podemos
acceder fácilmente a estos argumentos examinando el contenido de los QueryFields. Como cualquier otro
objeto de la clase TStrings, podemos acceder a cada valor utilizando la propiedad Values. De esta forma,
en el caso del ejemplo anterior, para ver el valor de los parámetros, haríamos algo como:

sParametro1 := Request.QueryFields.Values[‘parametro1’]
sParametro2 := Request.QueryFields.Values[‘parametro2’]

¿Ha rellenado alguna vez un formulario? Seguro que sí. Hoy en día, para realizar cualquier operación en
una página web le exigen que rellene uno. Tanto si es para solicitar soporte técnico, comprobar su correo
electrónico mediante web o pedir información sobre un producto, tiene que rellenar mil campos. La
verdad es que los formularios son útiles y proporcionan una gran potencia a la hora de realizar
aplicaciones web. Supongamos que tenemos un formulario que tiene dos campos de texto y un Checkbox.
En HTML, crearíamos algo como:

<form method=”post” action=”http://localhost/scripts/campos.dll/post”>

Nombre <input type=”text” name=”nombre”>
Apellidos <input type=”text” name=”apellidos”>
¿Es mayor de edad? <input type=”checkbox” name=”MayorDeEdad” value=”EsMayor”>
<input type=”submit” name=”Submit” value=”Mandar”>

Para acceder a los valores de los campos, hacemos algo similar a lo anterior salvo que en este caso
utilizamos la propiedad ContentFields. De esta forma, para ver el valor del campo “nombre”, haríamos:

sNombre := Request.ContentFields.Values[“nombre”]

Hay una diferencia con respecto a los Checkboxes. El valor de un CheckBox solamente esta contenido en
los ContentFields cuando el Checkbox está seleccionado. Por ello, antes de leer el valor, muchas veces
conviene hacer una comprobación viendo si el método IndexOfName devuelve un valor mayor que –1. En
caso afirmativo, podemos leerlo de la forma anterior. Un punto importante a recordar, aunque pertenezca
más a un curso de HTML que de Delphi, es que solamente se puede asociar un formulario a una acción.
Directamente con HTML no se podría tener dos botones que realicen dos acciones diferentes en un
mismo formulario, aunque con un poco de JavaScript este problema se podría solucionar.

Dame una respuesta

Bueno, ya sabemos como acceder a los campos que se pasa a una petición HTTP. Sabemos como leer los
valores de un GET y de un POST. Supongamos que leemos todos estos valores y los procesamos. ¿Cómo
podemos mostrar un resultado? Como era de esperar, al igual que existe un TWebRequest, existe un
TWebResponse, y de la misma forma, existen tres descendientes: TISAPIResponse, TCGIResponse y
TWinCGIResponse. Una respuesta a una petición HTTP consta de tres pasos. Primero, se debe especificar

5
 Programación Web- Proporcionando dinamismo a la red(II)
el código de la respuesta. Existen cinco categorías, diferenciadas por el primer dígito del código. Los
números de la forma 1XX indican que se va a mandar información y que la solicitud no se ha procesado
de manera completa. 2XX corresponde al éxito, indicando que la petición se ha recibido correctamente y
se ha realizado. En el grupo del 3XX se encuentran las redirecciones, necesitándose más información por
parte del cliente antes de completar la solicitud. Si ha habido un error por parte del cliente, se devuelve un
número correspondiente a la categoría 4XX. Por último, si se ha producido un error en el servidor, se
responde con 5XX. En el RFC del protocolo HTTP figura una lista completa de estos errores. En Delphi,
indicamos la respuesta rellenando la propiedad StatusCode. El siguiente paso consiste en devolver el
contenido de la respuesta. Tenemos dos formas para realizar esto, utilizando la propiedad Content cuando
se trate de una cadena o la propiedad ContentStream cuando queramos responder con un descendiente del
TStream. Para finalizar, y como tercer paso, lo único que nos queda por hacer es indicar que estamos
listos para mandar la respuesta. Podemos utilizar el método SendResponse cuando se trate de información
que no esté contenida en la cabecera de la respuesta (como por ejemplo un fichero, datos, etc) o bien
SendRedirect cuando vayamos a devolver únicamente una URL. Delphi nos facilita los tres pasos
proporcionándonos las propiedades y métodos necesarios. Sin embargo, es conveniente saber lo que esta
pasando detrás del escenario para poder comprender mejor el funcionamiento. Ya tenemos los suficientes
conocimientos teóricos para poder empezar con las prácticas.

Manos a la obra
Por experiencia propia, siempre he creído que se puede entender mejor lo que hace un trozo de código si
se puede depurar y ver paso a paso cada instrucción. De la misma forma que se puede depurar una
aplicación normal en Delphi, se puede hacer lo mismo con una DLL. Pero en este caso hay que seguir
una serie de pasos de configuración. A continuación se describe lo que hay que hacer para poder depurar
con PWS y con IIS. En ambos casos, la DLL tiene que encontrarse en el directorio scripts.

Personal Web Server

1. Abra el proyecto.
2. En Run|Parameteres ponga <PathInfo>\inetinfo.exe en el campo Run y –e w3svc en el
campo Parameters. <PathInfo> es la ruta al ejecutable inetinfo.exe
3. Ponga los puntos de ruptura y ejectue el programa con la tecla F9.
4. Ahora abra el navegador y llame a la aplicación.

Internet Information Server

Por defecto, IIS corre como un servicio en NT. Para poder depurar, hay que cambiar unas entradas en el
registro del sistema para que corra como un proceso. En los ficheros que acompañan este artículo, se
encuentran dos archivos con la extensión reg que modifican el registro a tal fin. El primero se llama
IISProcess.reg y modifica el registro para que IIS corra como un proceso. El segundo es para deshacer los
cambios (IISService.reg).

1. Ejecute el Administrador de Usuarios de NT. Seleccione el menú Derechos de usuario y

asigne al usuario con la que va a depurar los siguientes permisos: Inicio de Sesión como Servicio, Actuar
como parte del Sistema Operativo, Generar Auditorias de Seguridad.
2. Ahora ejecute el archivo IISProcess.reg haciendo doble-click sobre el.
3. Pare los servicios WWW, FTP y IIS Admin. desde el icono de Servicios del Panel de Control.
Además seleccione el método de arranque Manual.
4. Reinicie el ordenador.
5. Siga los mismos pasos que en el caso del Personal Web Server.

Todos los ejemplos tienen una página HTML muy simple que sirve para hacer las llamadas a la DLL, que
debería copiarse al directorio público del servidor web (por defecto, c:\inetpub\wwwroot). Para mayor
compatibilidad, la dirección URL utilizada es localhost. Windows a veces olvida la direcci ón
correspondiente (127.0.0.1), por ello si ve que esta tendiendo problemas, puede cambiar todas las
llamadas para que apunten al nombre de la máquina o añadir localhost al fichero HOSTS de su sistema.
6
 Programación Web- Proporcionando dinamismo a la red(II)
El ejemplo 1 muestra el uso de una acción por defecto y además utiliza la propiedad Content para
devolver una cadena HTML como respuesta a una petición. Podríamos haber asignado toda la cadena
directamente, pero es más claro y limpio utilizar un StringList. En el siguiente ejemplo, vemos como
acceder a las variables GET y POST, y de nuevo utilizamos Content como método de respuesta. Por
último, en el tercer ejemplo, examinamos algunas de las distintas formas de responder a una petición
(aparte de lo ya visto en los ejemplos anteriores). Invito al lector a que estudie bien el código de estos
ejemplos, son fáciles pero es importante comprenderlos bien.

Lo que viene
Lo siguiente que veremos los componentes básicos que se utilizan en Delphi para aplicaciones web, la
familia del TPageProducer. Además mostraremos como utilizar Cookies para mantener información de
estado, y todo ello nos servirá para enlazar nuestras aplicaciones con bases de datos, y así aprovechar al
máximo toda la potencia del WebBroker.