Introducción a la tecnología web
De todas las aplicaciones que se han construido sobre Internet, la World Wide Web (WWW o simplemente web) ha sido la más popular, tanto que, muchas personas cuando escuchan el término "Internet" realmente imaginan la web. La web puede definirse como un sistema de documentos de hipertexto interrelacionados entre sí y accesibles a través de Internet. Se dice que son documentos de hipertexto o hipermedios, por su capacidad de contener diferentes medios de comunicación: texto, imágenes, sonido, vídeo, enlaces, etc.
La popularidad de la web puede adjudicarse a su facilidad de uso y por ser el más exitoso de los sistemas distribuidos en la actualidad. Los documentos se almacenan en computadoras distintas, con sistemas operativos diversos, generados de fuentes heterogéneas, pero esto es transparente para el usuario. De hecho, para el usuario todos los documentos del mundo parecen ser parte de un único sistema, lo cual es fundamento de lo que se define como un sistema distribuido.
Para responder a los ejercicios de este material, cree un repositorio de control de versiones. Por ejemplo, un repositorio privado de git en BitBucket (sugerencia nombre su repositorio de la forma cursoweb_nombre_estudiante
). Invite al profesor como colaborador del repositorio (usuario del profesor en BitBucket: jeissonh
). Clone el repositorio en su máquina local. Cree una carpeta por cada uno de los capítulos de este material, algo como:
intro/ xml/ html/ css/ js/ php/
Cada vez que resuelva un ejercicio, cree una subcarpeta dentro del capítulo al que pertenece. Utilice como nombre de la carpeta del ejercicio, el identificador del ejercicio. Por ejemplo, use web_vs_desktop
y no Ejercicio 1.2
, ya que los números de ejercicios cambian conforme se agregan o mueven éstos por el documento.
¿Por qué hay tanto interés en crear aplicaciones web en lugar de aplicaciones de escritorio? Compare las ventajas y desventajas de cada una. Escriba sus percepciones en un documento de texto, en una carpeta intro/web_vs_desktop
.
Represente los eventos que considere más relevantes de la historia de la web (siguiente sección) en una línea de tiempo. Dibuje la línea de tiempo en una imagen vectorial en formato Scalable Vector Graphics (SVG). Puede utilizar el software libre Inkscape. Guarde su imagen en control de versiones, en la carpeta intro/history_timeline
.
Historia
La web fue conceptualizada en un artículo de 1989 de Tim Berners-Lee, quien se convertiría en uno de sus grandes líderes. A finales de 1990, Berners-Lee desarrolló el Protocolo de transferencia de hipertexto (HTTP, HyperText Transfer Protocol), el primer servidor web llamado CERN-httpd
; el primer navegador llamado WorldWideWeb
, que también era un editor web; el lenguaje de marcado de hipertexto (HTML, HyperText Markup Language); y las primeras páginas web que hablaban sobre el proyecto mismo.
La aparición pública de la web fue en 1991, cuando Berners-Lee describió el proyecto en un grupo de noticias (Usenet newsgroup). Había nacido un mecanismo eficiente que permite a cualquiera ser autor, compartir material de interés al mundo, y hacer referencia al existente a través de hiper-enlaces.
La difusión de la web fue lenta. Inicialmente fue adoptada por universidades y grupos científicos. Los documentos web eran muy sencillos y la mayoría de navegadores corrían en modo texto, unos pocos eran gráficos como el escrito por Berners-Lee en una NeXT. Desde 1992 muchos navegadores se construyeron, pero el más influyente de todos fue Mosaic.
En 1993 el National Center for Supercomputing Applications (NCSA) de la University of Illinois en Urbana-Champaign (UIUC), introdujo el navegador gráfico Mosaic, como un proyecto de investigación. NCSA licitaba su código fuente a otras compañías para que crearan sus propios navegadores, incluso comerciales. Tras de graduarse, el líder del proyecto Mosaic, Marc Andreessen, fundaría la compañía Netscape en 1994, para comercializar su navegador Netscape Navigator, el cual corría transparentemente entre diversos sistemas operativos. Era gratis para uso no comercial, por lo que se convirtió en el navegador más usado del mundo.
En 1994 Berners-Lee funda el World Wide Web Consortium (W3C) en el Instituto Tecnológico de Massachusetts (MIT, Massachusetts Institute of Technology), apoyado por varias instituciones y empresas con el fin de crear estándares y recomendaciones para mejorar la calidad de la web.
La primera guerra de navegadores
En 1995 Microsoft incluye Internet Explorer 1.0 en Windows 95, basado en código fuente de NCSA Mosaic. La versión 2.0 fue gratuita incluso para uso comercial. Lentamente Internet Explorer va tomando popularidad y mercado de Netscape, lo que generaría la primera guerra de navegadores.
Los ataques entre estos dos navegadores consistían en la inclusión de funcionalidades novedosas para atraer tanto usuarios como autores de sitios web. Por ejemplo, Netscape desarrolló JavaScript a finales de 1995, que un año más tarde sería imitado por el JScript de Microsoft, en la versión 3 de Internet Explorer. En esa versión particular, Microsoft incluyó una parcial implementación de las hojas de estilo en cascada (CSS, Cascading Style Sheets) sugeridas por el W3C pero aún no estandarizadas.
En 1997 Netscape fusionó su Netscape Navigator con otro conjunto de programas para correo electrónico, composición web, calendario, etc. Al suite se le llamó Netscape Communicator, nombre que serviría para confusiones. Microsoft integró Internet Explorer 4 con Windows y desalentó desde el sistema operativo el uso de cualquier otro navegador. Netscape no compitió contra esto, ni tenía sentido. Desde 1998 el 80% del mercado que tenía Netscape pasó a sumar el 96% que tenía Internet Explorer 5 en el 2002. La guerra de los navegadores había finalizado y también el rápido tren de innovaciones; tan evidente que Microsoft no volvería a hacer cambios significativos en su navegador desde el 2001 al 2006.
A inicios de 1998 Netscape libera el código fuente de Netscape Communicator 4.0 en el proyecto Mozilla. La comunidad descartaría luego dicho código debido a su complejidad, poca modularización, al gran volumen de pulgas y otros inconvenientes; y empezó la elaboración de un nuevo motor de navegador (web browser engine) hecho desde cero, al cual se le llamó, Gecko, y sería el motor de "rendering" de Firefox y el nuevo Netscape Communicator, que finalmente sería descontinuado a inicios del 2008.
El proceso de estandarización
La guerra de navegadores (aproximadamente de 1995 a 1998) también tuvo consecuencias muy negativas. Ambos, Netscape Navigator e Internet Explorer, ofrecían características novedosas incompatibles entre sí, es decir, dialectos de HTML distintos que provocaron que los autores de millones de páginas tuvieran que escoger por uno o el otro. Era común ver imágenes indicando que el sitio se veía mejor con un navegador particular, incluso hasta de una versión específica.
Mientras tanto el proceso de estandarización avanzaba lentamente. En junio de 1993 el Consorcio Web (W3C) propone varios borradores de estandarización y en noviembre de 1995, la Internet Engineering Task Force (IETF) aprueba el HTML 2.0 que luego se convertiría en estándar internacional en 1997. El W3C propone HTML 3.0 en abril de 1995 pero la IETF no realiza ninguna acción. Los navegadores tomarán luego ideas de estas iniciativas en proceso y las implementarán a su manera para atraer usuarios.
A inicios de 1997 la IETF traslada la responsabilidad de estandarización al W3C, quien publicaría recomendaciones con una eficiencia mayor. Se publica el HTML 3.2 adoptando etiquetas y atributos de marcado visual de Netscape (como b
y font
). A final del mismo año, el W3C presenta el trabajo de estandarización más notorio hasta la fecha, conocido como HTML 4.0. Un esfuerzo que considera las extensiones derivadas de la guerra de navegadores y las raíces del HTML. En ella, las etiquetas de marcado visual serían desaprobadas ("deprecated") en favor de CSS; pero su uso se había difundido tanto que el W3C decidió generar tres variaciones del HTML 4.0:
- HTML 4.0 Strict. Prohíbe elementos "deprecated".
- HTML 4.0 Transitional. Permite elementos "deprecated".
- HTML 4.0 Frameset. Permite construir páginas basadas en "frames", con los elementos
frameset
yframe
.
Dos años después, a finales de 1999, se le haría una ligera modificación al estándar HTML 4.01, cuya variación estricta (HTML 4.01 Strict) sería adoptado como estándar internacional (ISO/EIC 15445:2000), suplantando la versión 2.0 de 1997. Tras ello, el trabajo de estandarización dejaría de lado al HTML para concentrarse en el XHTML.
En febrero de 1998 el W3C publicó el estándar XML (Extensible Markup Language). En enero de 2000 se reformuló HTML 4.01 como una aplicación XML en lo que conoce como XHTML 1.0. Una actualización XHTML 1.1 se emitió como recomendación en mayo de 2001 que permite modularizar el HTML para necesidades específicas, las más sobresalientes han sido XHTML-Basic que incluye el conjunto mínimo de características que cualquier navegador debe soportar, incluso de dispositivos móviles y XHTML-MP (mobile profile) con controles aptos para dispositivos móviles.
Entre agosto de 2002 y julio de 2006, el W3C trabajó en XHTML 2.0 que sólo alcanzó el nivel de notas y no de recomendación. En el 2008 el W3C consideraría como base del futuro (X)HTML 5.0, un borrador llamado (X)HTML5 desarrollado por un grupo de interesados, compuesto principalmente por fabricantes de navegadores alternativos (Mozilla Foundation, Opera Software y Apple), ajenos al W3C, que se autodenominaron WHATWG (Web Hypertext Application Technology Working Group). A diferencia de XHTML 2.0, (X)HTML5 estaría más centrado en el desarrollo de aplicaciones web y no en la especificación de documentos. [Nota: En este documento se usarán los términos HTML y XHTML para referirse a cada notación por separado, o (X)HTML cuando algo aplique a ambas por igual].
La segunda guerra de navegadores
Los navegadores en guerra tuvieron equipos de desarrollo enfocados en agregar funcionalidad no estandarizada tan rápido como fuese posible, con poco control de calidad. Esto llevó a que ambos navegadores, Netscape Navigator e Internet Explorer no se apegaran a los estándares, fuesen "pulgosos" e inseguros. Pese de hacerlo público, el código fuente de Netscape fue descartado por la Fundación Mozilla. Por su parte, Microsoft tras ganar la guerra, mantuvo su navegador en el letargo por varios años.
Un navegador no mencionado es Opera. Inició en 1994 como un proyecto de investigación de la compañía noruega Telenor y disponible al público desde 1996 en forma comercial o gratuito con publicidad; hasta la versión 8.5 en setiembre de 2005, en que se distribuye sin costo ni publicidad alguna. Se caracterizó por ser el primer navegador en apegarse a los estándares, influir activamente en ellos, y en la inclusión de características amigables para el usuario, por ejemplo, el uso de "tabs", "mouse gestures", velocidad, seguridad y correr en dispositivos móviles.
La Fundación Mozilla siguió estas características en su navegador gratuito Firefox. Con el objetivo de crear nuevos estándares web que serían sometidos al W3C para aprobación, la Fundación Mozilla y Opera Software fundaron en el 2004 el grupo de trabajo WHATWG (Web Hypertext Application Technology Working Group), al cual se uniría Apple posteriormente.
Las primeras versiones del navegador de Mozilla aparecieron a finales del 2002, con nombres que después serían cambiados por conflictos con otras compañías, hasta quedar Firefox, el cual se liberó en noviembre de 2004. Desde el 2003 Mozilla Firefox empezó lentamente a atraer usuarios de Internet Explorer, en especial por sus problemas y la falta de iniciativa de Microsoft por corregirlos.
Microsoft reaccionó hasta octubre de 2006 con Internet Explorer 7, imitando características de Opera y Firefox. Esto no logró detener la creciente tasa de usuarios que seguían cambiando a Firefox. Por su parte, una semana después, Mozilla liberó Firefox 2.0 con mejoras de usabilidad y seguridad, lo que pondría en evidencia la segunda guerra de navegadores. Esta vez luchando por proveer mayor facilidad de uso y apego a los estándares.
En el 2003 Microsoft anunció que descontinuaría Internet Explorer for Mac. Apple inició el trabajo de crear un navegador que lo reemplazara, ya que era su navegador por defecto, y a partir del motor KHtml usado en Konkeror de KDE generó WebKit y el navegador Safari que apareció en el mismo año.
En el 2008 Google libera el navegador Chrome basado en WebKit. La presencia de estos nuevos navegadores siguen reduciendo el número de usuarios de Internet Explorer [De acuerdo a la estadísticas del W3C en http://www.w3schools.com/browsers/browsers_stats.asp]. Microsoft reacciona con la versión 8 en marzo de 2009 imitando funcionalidades e incrementando el apego a los estándares. Esta guerra se mantiene hasta el presente, donde cada fabricante libera versiones con frecuencia siguiendo la misma estrategia.
Aunque no es un estándar aún, la segunda guerra ha llevado a la mayoría de navegadores a implementar (X)HTML 5.0 o al menos las secciones más estables de sus borradores.
Arquitectura web
Un sitio web es un mecanismo de comunicación digital entre autores y visitantes basado en la arquitectura web: un modelo cliente-servidor cuya forma más simple se aprecia en la fig_arqweb y se explica a continuación en forma muy general.
El autor que quiera publicar un sitio web, construye un conjunto de páginas web en notación (X)HTML junto con imágenes, estilos y otros medios, y las almacena en una computadora que está siempre conectada a Internet, a la cual se le llama el servidor. Un programa especial, llamado servidor web, el cual tiene acceso de lectura a dichas páginas, estará siempre en esta computadora escuchando por un puerto TCP (Transmission Control Protocol), normalmente el 80 u 8080.
Un lector que quiera visitar el sitio debe conocer la dirección del servidor, es decir su número IP, ya sea introduciéndolo directamente o a través del servicio de nombres de dominio (DNS, Domain Name Service) y el puerto donde el servidor web está escuchando. El lector carga un programa especial en su computadora llamado navegador web (web browser) e ingresa en él la dirección del servidor y el puerto, empleando una notación estándar conocida como localizador uniforme de recursos (URL). El navegador intentará establecer una conexión TCP con el servidor al puerto indicado o al 80 si se omite. El servidor web aceptará la conexión. A partir de este momento el cliente y el servidor pueden comunicarse libremente, pero para que ambos puedan entenderse se necesita un idioma común: el protocolo de transferencia de hipertexto (HTTP, HyperText Transfer Protocol).
El protocolo HTTP establece que el cliente, también conocido como user agent, siempre hace solicitudes de recursos para mostrarlos al usuario, y el servidor responde a ellas, no el recíproco. Las solicitudes del cliente y las respuestas del servidor están codificadas como se verá luego.
En lo que resta de esta sección se explicarán los conceptos que componen la arquitectura web con más detalle y en la siguiente sección, el proceso típico en que un autor construye su sitio web y lo hace público para que los visitantes interaccionen con él.
El servidor web
Un servidor web es un programa cuya ejecución es persistente, a veces llamado servicio o demonio, en un equipo conectado a Internet, esperando conexiones de clientes usualmente por el puerto 80. Una vez establecida una conexión, el cliente solicita repetitivamente recursos al servidor mediante el protocolo HTTP y éste responde a cada una de ellas. El término servidor web también se usa para hacer referencia al hardware que corre este programa, pero en este documento se usará sólo para referirse al software.
Cualquier persona puede implementar un servidor web escribiendo un programa que espere conexiones en algún puerto TCP y hable por él HTTP. Sin embargo, para la mayoría de situaciones, es apremiante utilizar un servidor web existente. La servidores_web lista los más populares en la actualidad.
Nombre | Fabricante | Licencia | Detalles |
---|---|---|---|
Apache HTTP Server | Apache | Libre (Apache License) | Rico en características y extensiones. Corre en la mayoría de sistemas operativos. Sirve un poco menos de la mitad de los sitios web del mundo. |
Internet Information Services (IIS) | Microsoft | Propietario / Comercial | Sólo se ejecuta en Windows Server. Sirve un poco menos de un tercio de las páginas web del mundo. |
nginx | Igor Sysoev | Libre (BSD) | Nació como una alternativa de Apache caracterizada por el alto rendimiento y bajo consumo de recursos. Corre en la mayoría de sistemas operativos. Sirve aproximadamente 15% de las páginas web del mundo. |
Google Web Server (GWS) | Uso interno | Sirve aproximadamente 2% de las páginas web del mundo. | |
lighttpd | lighttpd | Libre (BSD) | Diseñado para ambientes de muy alto rendimiento donde la velocidad es un factor crítico. Es limitado en cuanto a funcionalidad. Sirve aproximadamente un 1% de las páginas web del mundo. |
Una empresa con bastantes años en el mercado pero sin presencia en internet, le contrata para crear su sitio web. ¿Qué preguntas haría al personal de la empresa con el fin de decidir cuál servidor web recomendar? Idee un par de escenarios. Los escenarios pueden tener esta estructura: "si las respuestas del personal fueran a y b, entonces el servidor recomendable sería w por esta razón: x".
Escoja e instale un servidor web en su máquina local, y establezca el document root de su servidor web como su repositorio local. Consulte la sección sobre el servidor web en este material, o la documentación de su servidor web, o tutoriales en línea, para ayudarse en la configuración del document root. Escriba en un archivo de texto un párrafo indicando la razón de elección del servidor web.
Verifique que pueda navegar por el repositorio local utilizando un navegador, y por tanto en http://localhost/. Su repositorio local y un servidor web local que le permite experimentar los cambios que haga en el código fuente, constituyen su ambiente de desarrollo local. Este ambiente es sumamente importante, porque permite al desarrollador implementar y probar sin afectar el sitio web en producción (el que atiende los visitantes reales).
Como prueba de su ambiente de desarrollo local haga lo siguiente. Cargue la dirección http://localhost/ en su navegador. Redimensione la ventana del navegador a un tamaño cercano a los 640x480 píxeles. Tome una captura de pantalla del navegador. Edite la imagen para que ocupe un tamaño reducido (unos 64kB o menos). Sugerencia, con Gimp puede cambiar la paleta de una imagen PNG a 256 colores (menú Image | Mode | Indexed
). Agregue esta imagen a su repositorio de control de versiones.
El cliente web o navegador web
Un navegador web, cliente web, o agente usuario ("user agent"), es un software que permite obtener, presentar, recorrer e interaccionar con recursos disponibles en la web. De los componentes de la arquitectura web, es el más conocido por los usuarios, ya que interaccionan directamente con él.
Un navegador web es una pieza de software compleja, por lo que usualmente está dividida en al menos dos módulos: el motor y la interfaz. El motor del navegador web ("web browser engine" o "rendering engine"), se encarga de analizar contenido ((X)HTML, imágenes, etc.), aplicarle estilos, modificar lo anterior con programas de JavaScript y presentar los resultados en la pantalla u otro medio. Por su parte, la interfaz del navegador web provee una barra de direcciones, marcadores, botones de navegación y otros controles que usan al motor del navegador web internamente para facilitar al usuario su interacción.
La separación entre el motor y la interfaz tiene una importante ventaja. El motor se distribuye en forma de biblioteca y permite que cualquier otra aplicación pueda usarlo. De esta forma, clientes de correo, aplicaciones de ayuda o cualquier software que usted quiera programar, puede manipular documentos web. La browser_engines muestra los motores de "rendereo" web más populares en la actualidad y los navegadores que los usan.
Nombre | Fabricante | Licencia | Navegadores |
---|---|---|---|
Gecko | Mozilla Project | Libre (L/GPL) | Firefox |
WebKit | Apple, KDE, Google, ... | Libre (LGPL/BSD) | Chrome, Safari |
Trident | Microsoft | Propietario | Internet Explorer |
Presto | Opera Software | Propietario | Opera |
Provea tres ejemplos de aplicaciones de escritorio o de móvil que podrían beneficiarse de utilizar un web rendering engine. Indique rápidamente para qué lo utilizarían.
El localizador uniforme de recursos URL
Un servidor web provee recursos en los que puede estar interesado un cliente. Todo recurso transferible entre el servidor y el cliente, debe estar identificado de forma única en el mundo mediante un localizador uniforme de recurso (URL, Uniform Resource Locator), que es una dirección junto con alguna información adicional para acceder al recurso. La sintaxis de un URL es
esquema://username:password@servidor:puerto/ruta?query_string#id_fragmento
Identifique y señale en los siguientes ejemplos hipotéticos, cada una de las partes del URL:
http://www.amazon.com/ http://www.w3.org/TR/html401/struct/tables.html#edef-CAPTION http://acme.co.cr:8080/index.php https://24.168.39.221/cgi-bin/book?id=4596098&action=remove ftp://msoto:w33n8rf1@down.antivirus.net/current/setup.exe
Escriba en un documento de texto sus resultados. Para cada URL, separe sus partes usando la siguiente estructura:
URL : Esquema : Servidor : Puerto : Ruta : Parámetros: Fragmento : Usuario :
Las partes de un URL son las siguientes:
- Esquema. También llamado Protocolo. Indica el propósito y la sintaxis del resto del URL. Entre muchos se pueden citar:
http
,https
,ftp
ymailto
. Por ejemplo, al procesar el URLhttp://www.amazon.com/
, un navegador hará un petición HTTP al servidorwww.amazon.com
en el puerto 80. Al procesar el URLmailto:chema@suizacentroamericana.cr
, lanzará un cliente de correo con un mensaje nuevo dirigido achema@suizacentroamericana.cr
. - Servidor. Es la dirección IP o el nombre de dominio si tiene registrado uno en el servicio de nombres de dominio (DNS, Domain Name Service). Permite identificar al servidor que provee el recurso, por ejemplo
drupal.org
. Dado a que DNS no es sensitivo a mayúsculas ni minúsculas, da lo mismo acceder aDRUPAL.org
, por ejemplo. - Puerto. Indica el puerto que será usado en la conexión TCP. Por ejemplo,
http://myserver.com:10000/
hará que el navegador establezca una conexión HTTP en el puerto 10000, probablemente para administración del servidor. Si se omite el puerto en el URL se asumirá el por defecto para el esquema usado. Por ejemplo, parahttp
es 80, parahttps
es 443 y paraftp
es 21. Una lista de protocolos y sus puertos por defectos puede a conveniencia consultarse en la Wikipedia. - Ruta. Contiene la ruta para encontrar el recurso dentro del servidor. Puede ser relativa al sistema de archivos del servidor o un "alias" que ayude a especificar el recurso, por ejemplo,
http://mibibl.net/revistas/acm.png
. Es muy probable que sea sensitiva a mayúsculas si el sistema de archivos del servidor lo es también. - Parámetros. Si el recurso es generado por una aplicación en el servidor web, a esta se le pueden enviar parámetros en forma de parejas
parametro=valor
y separadas por ampersands (&
) si son varias parejas, por ejemplo,https://mibibl.net/revista.php?id=23091&action=devolucion&user=chema
. A esta lista de parámetros se le suele llamar "query string". - Identificador de fragmento. Es un nombre que sirve para identificar una parte (fragmento) o un punto particular de un documento web. Cuando se especifica un identificador de fragmento en un URL, provoca que el navegador cargue el documento y automáticamente se desplace ("scroll") hasta el fragmento en cuestión. Por ejemplo,
http://misitio.co.cr/docs/tesis.html#Cap03
. - Usuario y contraseña. Si para acceder al recurso se necesita que el visitante se autentique, algunos protocolos permiten indicar las credenciales en el URL mismo. Es poco común y una práctica no recomendada incluir contraseñas, ya que el URL normalmente es público y carece de seguridad. Ejemplo,
ftp://mmortadela@sjmuni.go.cr/vaca/mu.pdf
.
Varios caracteres, como el slash (/
), el signo de pregunta (?
) y el espacio en blanco, tienen un significado especial en un URL. Si un usuario necesita incluir estos caracteres en un URL pero sin su significado especial, investigue y explique cómo se puede hacer. Convierta el siguiente URL en uno válido:
http://localhost/f.php?code="f(n) {return n ? n/f(n-1) : 1;}"
El protocolo de transferencia de hipertexto HTTP
La arquitectura web establece que un servidor web provee al mundo recursos identificados de forma única con URLs. Un cliente web o navegador web interesado solicita estos recursos y el servidor responde con ellos. Las convenciones usadas en el trasiego de estos recursos entre el cliente y servidor las estalece el protocolo de transferencia de hipertexto (HTTP, Hypertext Transfer Protocol).
Cuando el cliente web necesita un recurso, emite un mensaje de solicitud HTTP (HTTP request) al servidor. El servidor web carga el recurso desde el disco, una base de datos, un programa o cualquier otra fuente, y responde con una respuesta HTTP (HTTP response).
Una sesión HTTP (HTTP session), es una secuencia de solicitudes-respuestas entre el navegador y el servidor web. En la versión HTTP/1.0 de 1996 se establece una sesión por cada transferencia. Es decir, se inicia la sesión, el cliente solicita un recurso, el servidor responde y se cierra la sesión inmediatamente. Para transferir un nuevo recurso se debe iniciar otra sesión HTTP. En la versión HTTP/1.1 de 1999 la sesión permite un número arbitrario de transferencias lo que agiliza la comunicación entre ambas partes.
El mensaje HTTP
En la http_message_format se puede ver que la estructura de los mensajes de solicitud y respuesta HTTP es la misma, pero varía el contenido de los primeros dos campos.
La http_message_examples muestra dos ejemplos de mensajes HTTP. Los cambios de línea son importantes por lo que se muestran en rojo. En las siguientes secciones se explica cada uno de los campos que conforman los mensajes HTTP.
Los navegadores sólo muestran el contenido del cuerpo de los mensajes al usuario, ocultando los tres primeros campos de los mensajes usados en la negociación con el servidor web. La extensión HTTP Headers para el navegador Chrome, y Live HTTP Headers para Firefox, permiten al usuario visualizar y estudiar los campos ocultos de los mensajes que se intercambiaron entre el cliente y el servidor durante la carga de una página.
Dibuje en una hoja carta los ejemplos de mensajes HTTP de la http_message_examples. Las siguientes subsecciones explican cada una de sus partes. Haga anotaciones rápidas sobre el dibujo de cada una de las partes. Haga las anotaciones pensando en que le ayudarán en el futuro, como referencia, a comprender de qué se trata cada una de las partes. Finalmente, escanee o tome una fotografía de su dibujo, y agréguela al repositorio de control de versiones. La imagen no debería superar los 200kB.
Request line
En la primera línea del mensaje de solicitud HTTP, llamada Request line, el cliente web indica al servidor el recurso de interés (un URL) y la acción que desea el servidor tome con dicho recurso. La sintaxis del Request line es:
METHOD URL HTTP_version
El protocolo HTTP define 9 acciones que un cliente web puede solicitar al servidor, reciben el nombre de Request methods y se listan en la http_request_methods. El protocolo HTTP indica que todo servidor web debe al menos implementar GET y HEAD, e idealmente OPTIONS.
Método | Descripción |
---|---|
GET |
Solicita una copia completa del recurso cuya identificación esta dada por el URL que le sigue. A través de directivas en el encabezado (el campo que sigue en el mensaje) se pueden hacer solicitudes condicionales (Conditional GET), por ejemplo, obtener una copia del recurso sólo si ha cambiado a partir de una fecha, o una solicitud parcial (Partial GET), por ejemplo, obtener sólo un segmento del recurso. Estos detalles se explican en el RFC-2616. |
HEAD |
Es idéntico al método GET excepto en que el servidor web no debe retornar un Message body en el mensaje de respuesta HTTP. Esto permite al cliente obtener metadatos de un recurso, como para saber si ha cambiado en el servidor u otros fines. |
OPTIONS |
Retorna los métodos HTTP que el servidor soporta para un recurso dado (con un URL) o en general por el servidor web mismo (con un '* ' en lugar de un URL). |
POST |
Envía datos, normalmente ingresados en un formulario web, en el campo Message body del mensaje de solicitud HTTP, al recurso identificado por el URL, normalmente un programa en el servidor que procesará o almacenará dichos datos. |
PUT |
"Sube" (upload) un recurso identificiado por el URL cuyo contenido es enviado en el Message body al servidor, el cual reemplaza el recurso anterior si existe. Se diferencia de POST en la semántica del URL. En POST el URL especifica una aplicación que recibe los datos y los procesa; mientras que en PUT el URL es la identificación del recurso mismo. |
PATCH |
Sirve para aplicarle modificaciones parciales a un recurso. |
DELETE |
Solicita al servidor eliminar el recurso identificado por el URL. Normalmente está deshabilitado por defecto en la mayoría de servidores web. |
TRACE |
Permite rastrear servidores intermedios que procesan la solicitud HTTP. Esto es útil para estudiar el comportamiento de servidores proxy en especial si implementan algún caché. |
CONNECT |
Transforma la solicitud en una conexión a un túnel TCP/IP para facilitar la comunicación segura (HTTPS) a través de un proxy HTTP no encriptado. |
Request header
El campo de encabezado de la solicitud HTTP (HTTP Request Header) permite al cliente proveer información adicional sobre la petición o sobre el cliente mismo al servidor. En este campo se escriben parejas Atributo=Valor
. El estándar HTTP define unos 19 atributos de los cuales sólo uno es obligatorio: Host
. Los atributos se pueden extender mientras los agentes (el servidor y el navegador) estén de acuerdo en ellos. La request_header_fields muestra algunos de estos atributos.
Campo | Descripción |
---|---|
Accept: |
Permite al cliente especificar los tipos de medios (MIME types) que son aceptables como respuesta. Ej.: Accept: text/plain; text/html; application/html+xml . Un asterisco indica que todas las categorías o todos los medios son aceptables (*/* se asume si no se especifica un atributo Accept ). Un párámetro q=valor indica la calidad aceptable, donde valor es un real entre 0.0 y 1.0; útil especialmente en vídeo o ciertos formatos. Si el servidor no puede responder con un formato aceptable, debe generar un mensaje con el status code 406 NOT ACCEPTABLE . |
Host: |
Permite especificar el servidor y el puerto que tiene el recurso solicitado, ya que la primera línea (Request line) no incluye estos valores y se necesitan para desambiguar en caso de servidores proxy u otros intermediarios. Es el único atributo obligatorio en HTTP/1.1. Ej.: Host: www.miservidor.com:8080 . |
Referer: |
Permite especificar el URL del recurso del cual se obtuvo el URL solicitado al servidor. Debería ser Referrer: , pero en el estándar aparece como Referer: . |
User Agent: |
Contiene información sobre el navegador o agente de usuario que solicita el recurso. Consta de varias parejas módulo/valor separadas por espacios y en orden de importancia. Todos los agentes de usuario deben proveer este atributo. Ej.: User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0.1) Gecko/20100101 Firefox/5.0.1 . |
Emtpy line
Es un cambio de línea compuesto nada más de dos caracteres: retorno de carro y avance de línea (CRLF, carriage-return y line-feed). En notación C se escribe como "\r\n"
. Aunque algunos servidores web aceptan un LF simple ("\n"
). Esta línea no debe tener ningún otro espacio en blanco.
Message body
Este es el único campo opcional del mensaje HTTP y su contenido varía dependiendo de la naturaleza del mensaje. También es el único que puede transportar información binaria (todos los demás son de texto).
Status line
En la línea Status line del mensaje de respuesta HTTP, el servidor indica al cliente web, un código y una explicación textual como resultado de procesar la solicitud previamente hecha. La sintaxis del Status line es:
HTTP_version status_code reason_phrase
El status_code
es un número y el reason_phrase
es un texto corto escogido por el servidor web y comprensible para seres humanos; el navegador no necesita analizarlo. El status_code
es entero de tres dígitos, donde el primer dígito indica una de las cinco clases de respuesta definidas por el estándar HTTP:
- Información. La solicitud fue recibida y está siendo procesada.
- Éxito. La solicitud fue recibida, entendida, aceptada y procesada exitosamente.
- Redirección. Se necesitan más acciones del cliente para completar la solicitud.
- Error del cliente. La solicitud es incorrecta por error de sintaxis o no se puede realizar.
- Error del servidor. El servidor falló al procesar una solicitud aparentemente válida.
Por ejemplo, el error 404 NOT FOUND
indica que el cliente especificó un URL de un recurso que no existe en el servidor. El RFC 2616 de HTTP/1.1 define 41 status_code
s, algunos de los más comunes son los siguientes:
200 OK
. La solicitud HTTP fue exitosa. Por ejemplo, si la solicitud fue un GET, la respuesta contendrá el recurso solicitado en el campoMessage body
; si la solicitud fue un POST, los datos enviados por el cliente fueron procesados exitosamente.204 NOT CONTENT
. El servidor procesó la solicitud exitosamente, pero no es necesario generar un recurso como respuesta y por ende el campoMessage body
está vacío.206 PARTIAL CONTENT
. El servidor responde con un fragmento del recurso solicitado, tal como fue pedido por el cliente web. Esto es de utilidad para continuar descargando un recurso incompleto o permitir varias descargas simultáneas en partes diferentes del mismo recurso. Esta funcionalidad es ampliamente explotada por los administradores de descargas (download managers).301 MOVED PERMANENTLY
. El recurso ha sido movido a otro URL y el cliente debe obtener el nuevo recurso con una nueva solicitud.302 FOUND
. No debería usarse. Normalmente se quiere decir 303.303 SEE OTHER
. El recurso está disponible en otro URL, el cual el cliente debe obtener con una solicitud nueva. Puede usarse para evitar sobrecargar un servidor web o redireccionar algún recurso.400 BAD REQUEST
. La sintaxis de la solicitud es incorrecta.401 UNAUTHORIZED
. El cliente intenta acceder a un recurso que está protegido y no ha provisto credenciales o las ha fallado. La respuesta incluye un reto al usuario, el cual debe proveer un nombre de usuario y contraseña.403 FORBIDDEN
. La solicitud es válida pero el servidor se niega a completarla, por ejemplo, tras varios intentos el usuario falla el proceso de autenticación.404 NOT FOUND
. El recurso no se encuentra pero podría estarlo en el futuro.410 GONE
. El recurso no se encuentra y nunca más lo hará. Es útil para avisar a los motores de búsqueda que eliminen el recurso de sus índices.500 INTERNAL SERVER ERROR
. Mensaje genérico, para cuando no hay uno 5XX más específico.501 NOT IMPLEMENTED
. El request method o alguna característica es válida ante el estándar, pero el servidor web no lo implementa.503 SERVICE UNAVAILABLE
. El servidor web no está disponible por sobrecarga o en mantenimiento. Normalmente una condición temporal.
Para revisar la lista completa de códigos de estado HTTP con los que puede responder un servidor, consúltese el RFC 2616.
Response header
El campo encabezado de respuesta HTTP (HTTP Response Header) permite al servidor enviar información adicional sobre la respuesta al agente de usuario. Utilizan la misma notación que los del campo encabezado de solicitud HTTP y también se pueden extender mientras los agentes estén de acuerdo en ellos. Algunos se explican en la siguiente tabla.
Campo | Descripción |
---|---|
ETag: |
Contracción de "Entity Tag". Es una cadena que permite identificar el estado del recurso, de tal forma que si se hace una modificación del recurso en el servidor, su ETag variará. Esto permite al cliente saber si su copia en el caché está actualizada o ha variado en el servidor. Ej.: Etag: "239876f-4b8c-429fe67474a80" . |
Location: |
Permite al servidor indicarle al agente de usuario que el recurso solicitado ha sido movido a un nuevo URL. El agente usuario debe entonces solicitar el nuevo recurso, lo que se conoce como una "redirección". |
Server: |
Contiene información sobre el servidor web que genera la respuesta. Consta de varias parejas módulo/valor en orden de importancia para identificar al servidor. Ej.: Server: Apache/2.2.9 (Debian) PHP/5.2.17-0.dotdeb.0 . |
WWW-Authenticate: |
Solicita al usuario autenticarse para acceder a un recurso en una respuesta 401 UNAUTHORIZED . Es seguido por el número de intentos permitidos. Ej.: WWW-Authenticate: 3 . |
Ejemplo de una sesión HTTP
Supóngase que el sitio web ubicado en www.ejemplo.com
está en construcción y tiene sólo dos recursos, un index.html
y una imagen img/ucr.png
. El contenido del recurso index.html
se encuentra en el some_index_page.
Desarrollo de aplicaciones web Presentación
En este curso el estudiante aprenderá a[...]