Los sitios web ASP.NET
El modelo de compilación
1. Del CGI al modelo ASP.NET 1.X
Para comprender el modelo de compilación de ASP.NET, vamos a trazar la evolución de las aplicaciones web.
El protocolo HTTP ha ido evolucionando de la mano de las páginas HTML. Se ha impuesto con rapidez la idea de que el contenido de las páginas debía generarse bajo demanda, en especial para presentar datos provenientes de una base de datos SQL.
a. La interfaz CGI
La primera técnica disponible fue el CGI (Common Gateway Interface). Además de páginas HTML estáticas -archivos cuyo nombre incluye una extensión .html- el servidor web alberga programas ejecutables. Una configuración particular indica al servidor que dichos programas se deben ejecutar cuando se solicitan ciertas URL concretas. El programa ejecutable invocado por el servidor decodifica la petición HTTP realizando una lectura sobre el flujo de entrada estándar (stdin en lenguaje C) y analizando las variables de entorno. La respuesta HTTP se escribe, a continuación, sobre el flujo de salida estándar (stdout); el servidor inserta, en ocasiones, encabezados HTTP y se envía todo al navegador. Si bien fueron indispensables durante la creación de las aplicaciones web, las CGI presentan numerosas limitaciones; el lenguaje de programación empleado, C o, a menudo, PERL, no está realmente adaptado a la situación. Además, la interfaz CGI genera demasiadas implementaciones específicas, que hacen menos robusta la solución. Por último, las CGI no presentan un buen rendimiento.
Con el objetivo de ilustrar la complejidad del desarrollo de una CGI se muestra, a continuación, en lenguaje C, el código de un programa que devuelve la hora al usuario cuyo nombre se pasa en la cadena de petición (query string).
#include "stdafx.h"
#include <time.h>
#include <stdio.h>
#include <sys/types.h>
#include <sys/timeb.h>
#include <string.h>
#include <stdlib.h>
int main(int argc, char* argv[])
{
// calcular la hora
char hora[128];
_strtime_s( hora, 128 );
// recuperar el nombre del usuario
char*q=getenv("QUERY_STRING");
char*nombre="";
if(q!=NULL)...
El rol del servidor web
1. El servidor IIS
a. El filtro ISAPI para ASP.NET
El servidor Internet Information Services (IIS) se ha integrado a la perfección con el conjunto del sistema operativo Windows. Da soporte a muchas tareas, aunque la implementación del protocolo HTTP sigue siendo su principal actividad.
Es el servidor web el que recibe las consultas HTTP emitidas por el navegador. Estas últimas no distinguen la tecnología del servidor, tan solo consideran los aspectos del lado cliente HTML, JavaScript, y HTTP.
Cuando se solicita al servidor una página con una extensión particular (.asp o .aspx, por ejemplo), éste delega su ejecución al servidor de aplicaciones correspondiente (ASP o ASP.NET) y, a continuación, envía el flujo HTML al navegador. Desde un punto de vista HTTP, el procedimiento es comparable a la interfaz CGI.
El servidor de aplicaciones ASP.NET se registra en IIS como filtro ISAPI.
b. Creación de un sitio web ASP.NET con IIS
El servidor IIS posee, para cada instancia, una carpeta que se corresponde con la raíz de las URL (el primer símbolo / que figura tras el nombre del servidor en una URL completa). La instalación por defecto prevé c:\inetpub\wwwroot como raíz, y en esta carpeta instala Visual Studio los sitios web.
Es posible crear un sitio web ASP.NET eligiendo el modo de acceso: Archivo, HTTP o FTP. El modo HTTP se corresponde con una explotación...
El pipeline HTTP de IIS
1. Funcionamiento de IIS
Nos interesaremos, ahora, por el funcionamiento del servidor web IIS. El protocolo HTTP se basa en un mecanismo de peticiones y respuestas entre el cliente (el navegador) y el servidor. Este mecanismo no varía de una tecnología de páginas dinámicas a otra.
a. Primeros pasos en HTTP con Telnet
Para estudiar los intercambios entre cliente y servidor es posible utilizar Telnet. Telnet es comparable a Minitel, pero se basa en el protocolo TCP/IP. Se trata, por tanto, de un terminal pasivo (teclado y pantalla) que es posible utilizar, afortunadamente, sobre cualquier puerto. Abriendo una sesión sobre el puerto 80 es posible hacerse pasar por un agente HTTP.
Telnet se ejecuta desde la línea de comandos y es aconsejable activar el echo local antes de realizar consultas HTTP. En efecto, el protocolo Telnet prevé que el servidor solicite o no al cliente mostrar por pantalla lo que se introduce por teclado. El protocolo Telnet también sabe interpretar la tecla de borrado de carácter. Aunque este no es el caso del protocolo HTTP que, por lo general, lo emplea un agente automático. En las manipulaciones siguientes se introduce un error en la consulta y habrá que retomarlo desde el principio. El echo local obliga al usuario a ver los caracteres conforme los introduce por el teclado, incluso si el servidor no se lo pide expresamente.
He aquí la sintaxis Telnet de activación del echo local en Windows XP y 7:
set localecho
El comando que establece la conexión con el servidor en el puerto 80 es idéntico en ambas versiones.
open localhost 80
A continuación, hay que ejecutar una consulta HTTP sobre una página web existente. Para realizar una primera prueba, vamos a escoger una página cuyo contenido sea corto, con el objetivo de facilitar el análisis, hora.asp, por ejemplo.
GET /hora.asp HTTP/1.1
Host: yo
La respuesta del servidor está compuesta por un encabezado y un cuerpo separados por una línea vacía. El encabezado define, en particular, el código de error (200=OK), el formato de salida (text/html), el tamaño en bytes del cuerpo (70 bytes). El cuerpo es, de hecho, la secuencia HTML interpretada por el navegador según el formato especificado (text/html). De este modo el navegador ignora el formato de dicha secuencia hasta la recepción...