HTTP, como hemos visto anteriormente, se caracteriza por ser un protocolo //stateless//, es decir, en el cual no se mantiene información de estado. Las transacciones se ejecutan con un requerimiento de un lado y una respuesta del otro. Esta aproximación puede parecer bastante simplista en el terreno de las aplicaciones cliente-servidor. Ninguna de las aplicaciones anteriores (FTP, Telnet) es stateless, con la posible excepción de NFS.
De hecho, NFS se implementa sobre el protocolo UDP, ni siquiera TCP. Esto porque está en mente principalmente el objetivo de conseguir buenos tiempos de respuesta, a costo de todo lo demás. Por otra parte, por la implementación en múltiples procesos de la mayoría de los servidores, es raro que dos requests consecutivos del mismo cliente sean atendidos por el mismo proceso.
En el caso de HTTP, esto puede llegar a ser un problema mayor. La forma en que CGI+HTML resuelven el tema de las aplicaciones Web es realmente muy limitada:
~- El usuario llena un formulario HTML y presiona "submit"
~- El servidor recibe el formulario HTML, lee las variables que hay en él, ejecuta algún efecto colateral y despliega otra página (posiblemente con un formulario también).
Formularios
Un formulario es un diálogo que forma parte de una página Web. Este diálogo está construído con un conjunto de elementos como:
~- Campos de texto de una o varias líneas
~- Checkboxes (opciones no excluyentes)
~- Radio buttons (opciones múltiples excluyentes)
~- Pull-down menus
~- Botones
Algunos de estos elementos tienen un //nombre//. Este nombre indica que el valor actual del elemento debe ser codificado y enviado al servidor en el momento del envío del formulario. Más información en http://www.wdvl.com/Authoring/HTML/Forms/ WDVL - Forms.
Precálculos y Validación en el lado del cliente
Es algo estándar actualmente que antes de enviar el formulario, un programa corriendo en un lenguaje embebido en el browser del cliente (típicamente Javascript) realice algunos cálculos. En la práctica esos cálculos significan detener el proceso de envío al servidor, bajo ciertas condiciones, generando una alerta al usuario. En otras ocasiones significan que algunos elementos del formulario adquieren nuevos valores que son calculados automáticamente en base a otros.
El ejemplo más típico de precálculo son los formularios que validan dígitos verificadores antes de que el usuario envíe la página.
El proceso de prevalidación tiene las siguientes ventajas:
~- Más rápido detectar errores
~- Menos carga del servidor
Notar que la prevalidación puede simplificar la programación de los scripts en el lado del servidor, pero eso no implica dejar de hacer ciertas aserciones para evitar uso malicioso (ej.: ingreso de una URL con variables directamente).
Proceso del formulario en el lado del servidor
El servidor recibe sólo pares del tipo //nombre=valor//. Normalmente el sofware en el lado del servidor tiene acceso a todos los recursos de esa máquina y por lo tanto puede ejecutar cualquier programa, conectarse a otros servidores, y producir cualquier tipo de efecto colateral que desee.
Desde el punto de vista funcional, este programa recibe entradas y genera una salida. Esta salida puede ser de cualquier tipo MIME aceptado por el browser que envió el formulario. Lo más típico es HTML pero no es raro ver imágenes generadas también (esto se usa en los ad-servers y todas las herramientas de user-tracking para estudiar patrones de navegación).
Hay varios problemas aquí:
~- ¿Qué pasa cuando no necesito desarrollar algo más complejo?
~- ¿Qué pasa si necesito varios pasos?
~- En particular, ¿qué pasa si hay un paso previo de autentificación?
Estas preguntas tienen todas una respuesta afirmativa, es decir, siempre hay solución. Pero contestar eso es lo mismo que decirle a alguien que es perfectamente posible hacer un programa que simplifique expresiones de algebra simbólica usando máquinas de Turing: se necesita en la práctica una forma de más alto nivel de describir el problema.
Lo extraño de todo esto es que normalmente no se busca tal forma, sino que simplemente se intenta parchar con las herramientas disponibles. Veremos una situación intermedia en que la aplicación es complementada por ciertos módulos de nivel medio.
