Protocolo http y WWW
Upcoming SlideShare
Loading in...5
×
 

Protocolo http y WWW

on

  • 395 views

Trata sobre el protocolo http y la WWW

Trata sobre el protocolo http y la WWW

Statistics

Views

Total Views
395
Views on SlideShare
395
Embed Views
0

Actions

Likes
1
Downloads
15
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Protocolo http y WWW Protocolo http y WWW Document Transcript

  • 1.2 Protocolo HTTP y la World Wide Web Índice La WWW como servicio de Internet...........................................................................................1 Breve historia de la WWW..........................................................................................................1 Fundamentos de la Web...............................................................................................................2 ¿Qué es el WWW?...................................................................................................................2 El Web es un soporte adecuado para:......................................................................................2 URIs (Universal Resource Identifier. RFC 2396)....................................................................3 URIs relativos..........................................................................................................................3 Arquitectura del WWW...............................................................................................................6 El protocolo http..........................................................................................................................8 HTTP: Características..............................................................................................................8 Por qué queremos conocer su funcionamiento........................................................................9 Protocolo HTTPS...................................................................................................................11 Servidores seguros.............................................................................................................11 Secure Socket Layer (SSL)................................................................................................11 Principales características del protocolo HTTP.....................................................................13 Tipos MIME...........................................................................................................................13 Etapas de una transacción HTTP:..........................................................................................15 Costes de conexión................................................................................................................16 Métodos HTTP.......................................................................................................................17 Peticiones en HTTP: GET y POST....................................................................................19 Una petición GET sigue el siguiente formato:...................................................................19 • Línea de petición.........................................................................................................20 • Cabecera de petición....................................................................................................20 • Parámetros de petición................................................................................................21 Respuestas en HTTP..........................................................................................................24 Códigos de respuesta del Servidor.....................................................................................26 Códigos de Información.................................................................................................26 Códigos de Petición Correcta.........................................................................................26 Códigos de Redirección.................................................................................................27 Códigos de Error de Cliente...........................................................................................27 Códigos de Error de Servidor........................................................................................29 Comandos adicionales de HTTP/1.1 (RFC 2068).............................................................30 Cabeceras comunes para peticiones y respuestas..............................................................30 Cabeceras para peticiones del cliente................................................................................31 Cabeceras para respuestas del servidor..............................................................................32 Tipos y Subtipos de Contenido..........................................................................................33 Persistencia en http –Cookies............................................................................................35 ...................................................................................................................................................36
  • La WWW como servicio de Internet La WWW (World Wide Web) o, de forma más coloquial, la Web, se ha convertido, junto con el correo electrónico, en el principal caballo de batalla de Internet. Ésta ha dejado de ser una inmensa “biblioteca” de páginas estáticas para convertirse en un servicio que permite acceder a multitud de prestaciones y funciones, así como a infinidad de servicios, programas, tiendas, etc. Breve historia de la WWW En 1989, mientras trabajaba en el CERN (Centro Europeo de Investigación Nuclear), Tim Berners-Lee empezó a diseñar un sistema para hacer accesible fácilmente la información del CERN. Dicho sistema empleaba el hipertexto para estructurar una red de enlaces entre los documentos. Una vez obtenida la aprobación para continuar el proyecto, nació el primer navegador Web, llamado World-WideWeb (sin espacios). En 1992 el sistema ya se había extendido fuera del CERN. El número de servidores “estables” había aumentado, alcanzando la sorprendente cifra de veintiséis. A partir de este punto, el crecimiento es espectacular. En 1993 la Web ya era merecedora de un espacio en el New York Times. Éste es el año del lanzamiento de Mosaic, un navegador para X-Window/Unix que con el tiempo se convertiría en Netscape y que fue un factor clave de popularización de la Web. En 1994 se fundó el WWW Consortium, que se convertiría en el motor de desarrollo de los estándares predominantes en la Web (http://www.w3c.org). A partir de ese momento, el crecimiento ya fue constante, convirtiéndose Página - 1 -
  • hacia finales de los noventa en el servicio insignia de Internet y dando lugar al crecimiento imparable de los servicios en línea que estamos experimentando actualmente. Fundamentos de la Web El éxito espectacular de la Web se basa en dos puntales fundamentales: el protocolo HTTP y el lenguaje HTML. Uno permite una implementación simple y sencilla de un sistema de comunicaciones que nos permite enviar cualquier tipo de ficheros de una forma fácil, simplificando el funcionamiento del servidor y permitiendo que servidores poco potentes atiendan miles de peticiones y reduzcan los costes de despliegue. El otro nos proporciona un mecanismo de composición de páginas enlazadas simple y fácil, altamente eficiente y de uso muy simple. ¿Qué es el WWW? – Es una red de recursos de información basada en los mecanismos siguientes: • Un esquema uniforme de nombres para localizar recursos en la Web (p.e. URIs), • Protocolos para acceder a estos recursos (p.e. HTTP), • Hipertexto para navegar fácilmente entre recursos (p.e. HTML). – Conjunto de servicios multimedia ofrecidos a través de Internet. El Web es un soporte adecuado para: – Integrar servicios en una sola plataforma (FTP, Telnet, correo, etc.) – Dispone de una herramienta gráfica (navegadores) que permite visualizar información o ejecutar programas. – Es un soporte adecuado para la ejecución de aplicaciones distribuidas ya que facilita el diseño en aspectos tales como: Página - 2 -
  • • Seguridad • Heterogeneidad • Errores. • Etc. URIs (Universal Resource Identifier. RFC 2396) – Dirección de los recursos disponibles en la Web. Normalmente se componen de tres partes: • El esquema de nombres del mecanismo usado para acceder al recurso. • El nombre de la máquina que aloja al recurso. • El nombre del recurso en forma de ruta de acceso (path). <esquema>://<máquina>[:puerto]/<ruta> <esquema>://<máquina>[:puerto]/<ruta>;<param>?<query>#<fragmento> – Esquemas • ftp File Transfer protocol • http Hypertext Transfer Protocol • mailto Electronic mail address • newsUSENET news • nntp USENET news mediante NNTP • file Nombre de archivo URIs relativos Página - 3 -
  • – Un URI relativo no contiene información sobre el esquema de nombres. Su ruta de acceso se refiere generalmente a un recurso que está en la misma máquina que el documento actual. • Pueden contener indicadores relativos de ruta. ⇒ (p.ej., ".." significa un nivel superior en la jerarquía definida por la ruta de acceso) • Pueden contener identificadores de fragmento. ⇒ Algunos URIs se refieren a una localización dentro de un recurso. Este tipo de URIs termina con un "#" seguido de un identificador de vínculo (llamado identificador de fragmento). Por ejemplo, aquí tenemos un URI que apunta a un vínculo llamando seccion_2: http://algunsitio.com/html/superior.html#seccion_2 Los URIs relativos se convierten en URIs completos a partir de un URI base. Como ejemplo de conversión de un URI relativo, supongamos que tenemos el URI base "http://www.acme.com/soporte/intro.html". El URI relativo de la siguiente línea de código de un vínculo hipertextual: <A href="proveedores.html">Proveedores</A> se expandiría al URI completo "http://www.acme.com/soporte/proveedores.html", mientras que el URI relativo de la siguiente línea de código de una imagen: <IMG src="../iconos/logo.gif" alt="logo"> se expandiría al URI completo "http://www.acme.com/iconos/logo.gif". En HTML, los URIs se usan para: • Crear un vínculo a otro documento o recurso. • Crear un vínculo a una hoja de estilo o script externos. • Incluir una imagen, objeto o aplicación en una página. • Crear un mapa de imágenes. • Enviar un formulario. • Crear un documento con marcos. Página - 4 -
  • • Citar una referencia externa. • Hacer referencia a convenciones de metadatos que describen un documento. Página - 5 -
  • Arquitectura del WWW El diseño del World-Wide Web sigue el modelo cliente-servidor: un paradigma de división del trabajo informático en el que las tareas se reparten entre un número de clientes que efectúan peticiones de servicios de acuerdo con un protocolo, y un número de servidores que las atienden (Malkin, 1993). En el Web, nuestras estaciones de trabajo son clientes que demandan hipertextos a los servidores. Para poner en marcha un sistema como éste ha sido necesario: a) Diseñar e implementar un nuevo protocolo que permitiera realizar saltos hipertextuales, esto es, de un nodo o lexia de origen a uno de destino, que podría ser un texto o parte de un texto, una imagen, un sonido, una animación, fragmento de vídeo, etc. Es decir, cualquier tipo de información en formato electrónico. Este protocolo se denomina HTTP (HyperText Transfer Protocol) y es el "lenguaje" que "hablan" los servidores del WWW. b) Inventar un lenguaje para representar hipertextos que incluyera información sobre la estructura y el formato de representación y, especialmente, indicar origen y destino de saltos hipertextuales. Este lenguaje es el HTML o (HyperTextex markup Language). c) Idear una forma de codificar las instrucciones para los saltos hipertextuales de un objeto a otro de la Internet. Dada la variedad de protocolos, y por tanto, formas de almacenamiento y recuperación de la información, en uso en la Internet, esta información es vital para que los clientes (ver el siguiente punto) puedan acceder a dicha información. d) Desarrollar aplicaciones cliente para todo tipo de plataforma y resolver el problema de cómo acceder a información que está almacenada y es accesible a través de protocolos diversos (FTP, NNTP, Gopher, HTTP, X.500, WAIS, etc.) y representar información multiformato (texto, gráficos, sonidos, fragmentos de vídeo, etc.). A este fin se han desarrollado diversos clientes, entre los que destaca la familia Mosaic, del NCSA (National Center for Supercomputer Página - 6 -
  • Applications) de la Universidad de Chicago, y su sucesor Netscape Navigator, de Netscape Communications Corporation. Página - 7 -
  • El protocolo http El protocolo HTTP (Hypertext Tranfer Protocol - Protocolo de Transferencia de HiperTexto) es el protocolo base de la WWW. Es un sencillo protocolo cliente-servidor que articula los intercambios de información entre los clientes Web y los servidores HTTP. La especificación completa del protocolo HTTP 1/0 está recogida en el RFC 1945. Fue propuesto por Tim Berners-Lee, atendiendo a las necesidades de un sistema global de distribución de información como el World Wide Web. Se trata de un protocolo simple, orientado a conexión y sin estado. La razón de que esté orientado a conexión es que emplea para su funcionamiento un protocolo de comunicaciones (TCP, transport control protocol) de modo conectado, un protocolo que establece un canal de comunicaciones de extremo a extremo (entre el cliente y el servidor) por el que pasa el flujo de bytes que constituyen los datos que hay que transferir, en contraposición a los protocolos de datagrama o no orientados a conexión que dividen los datos en pequeños paquetes (datagramas) y los envían, pudiendo llegar por vías diferentes del servidor al cliente. El protocolo no mantiene estado, es decir, cada transferencia de datos es una conexión independiente de la anterior, sin relación alguna entre ellas, hasta el punto de que para transferir una página Web tenemos que enviar el código HTML del texto, así como las imágenes que la componen, pues en la especificación inicial de HTTP, la 1.0, se abrían y usaban tantas conexiones como componentes tenía la página, trasfiriéndose por cada conexión un componente (el texto de la página o cada una de las imágenes). HTTP: Características – Sin estado: • Cada petición/respuesta es una operación distinta, no se mantiene información entre peticiones. • Solución: cookies. Página - 8 -
  • – Cada operación requiere un ciclo petición/respuesta • Ineficiente • Solución: programas en el lado del cliente Por qué queremos conocer su funcionamiento – Es útil para una mejor comprensión del funcionamiento de los formularios en HTML – Es muy útil para la programación de CGIs – Proporciona información sobre los mensajes de error de los servidores. Desde el punto de vista de las comunicaciones, está soportado sobre los servicios de conexión TCP/IP, y funciona de la misma forma que el resto de los servicios comunes de los entornos UNIX: un proceso servidor escucha en un puerto de comunicaciones TCP (por defecto, el 80), y espera las solicitudes de conexión de los clientes Web. Una vez que se establece la conexión, el protocolo TCP se encarga de mantener la comunicación y garantizar un intercambio de datos libre de errores. Página - 9 -
  • HTTP se basa en sencillas operaciones de solicitud/respuesta. Un cliente establece una conexión con un servidor y envía un mensaje con los datos de la solicitud. El servidor responde con un mensaje similar, que contiene el estado de la operación y su posible resultado. Todas las operaciones pueden adjuntar un objeto o recurso sobre el que actúan; cada objeto Web (documento HTML, fichero multimedia o aplicación CGI) es conocido por su URL. Página - 10 - El Web se basa en el protocolo de la red de Internet (TCP/IP) Tantos clientes como servidores utilizan el protocolo HTTP Funcionamiento de una transacción
  • Protocolo HTTPS Existe una variante de HTTP llamada HTTPS (S por secure) que utiliza el protocolo de seguridad SSL (secure socket layer) para cifrar y autenticar el tráfico entre cliente y servidor, siendo ésta muy usada por los servidores Web de comercio electrónico, así como por aquellos que contienen información personal o confidencial. • Servidores seguros – Se entiende por Servidor Seguro un servidor de páginas Web que establece una conexión cifrada con el cliente que ha solicitado la conexión, de manera que nadie, salvo el servidor y el cliente, puedan tener acceso a la información transmitida de forma útil. – El uso de servidores seguros es un elemento imprescindible en todos aquellos servicios que utilicen información confidencial. – Secure Socket Layer (SSL) – Implementa un protocolo de negociación para establecer una comunicación segura a nivel de socket (nombre de máquina más puerto), de forma transparente al usuario y a las aplicaciones que lo usan. – Se introduce como una especie de nivel o capa adicional del modelo OSI, sustituyendo los sockets del sistema operativo, lo que hace que sea independiente de la aplicación que lo utilice, y se implementa generalmente en el puerto 443. De manera esquemática, el funcionamiento de HTTP es el siguiente: el cliente establece una conexión TCP hacia el servidor, hacia el puerto HTTP (o el indicado en la dirección de conexión), envía un Página - 11 -
  • comando HTTP de petición de un recurso (junto con algunas cabeceras informativas) y por la misma conexión el servidor responde con los datos solicitados y con algunas cabeceras informativas. Página - 12 -
  • Principales características del protocolo HTTP • Toda la comunicación entre los clientes y servidores se realiza a partir de caracteres de 8 bits. De esta forma, se puede transmitir cualquier tipo de documento: texto, binario, etc., respetando su formato original. • Permite la transferencia de objetos multimedia. El contenido de cada objeto intercambiado está identificado por su clasificación MIME. • Existen tres verbos básicos (hay más, pero por lo general no se utilizan) que un cliente puede utilizar para dialogar con el servidor: GET, para recoger un objeto, POST, para enviar información al servidor y HEAD, para solicitar las características de un objeto (por ejemplo, la fecha de modificación de un documento HTML). • Cada operación HTTP implica una conexión con el servidor, que es liberada al término de la misma. Es decir, en una operación se puede recoger un único objeto. • No mantiene estado. Cada petición de un cliente a un servidor no es influida por las transacciones anteriores. El servidor trata cada petición como una operación totalmente independiente del resto. • Cada objeto al que se aplican los verbos del protocolo está identificado a través de la información de situación del final de la URL. Tipos MIME Los tipos MIME constituyen un modo estándar de clasificar tipos de archivos en Internet. Los programas de Internet como los servidores de Web y los navegadores de Web, tienen una lista de Página - 13 -
  • tipos MIME para poder transferir archivos del mismo tipo del mismo modo, sea cual sea el sistema operativo que estén utilizando. Página - 14 -
  • Etapas de una transacción HTTP: – Un usuario accede a una URL. • Seleccionando un enlace de un documento HTML • Introduciéndola directamente en el campo Location del cliente Web. – El cliente Web descodifica la URL, separando sus diferentes partes. • Identifica el protocolo de acceso, la dirección DNS o IP del servidor, el posible puerto opcional (80 por defecto) y el objeto requerido del servidor. – Se abre una conexión TCP/IP con el servidor, llamando al puerto TCP correspondiente. – Se realiza la petición, constituida por: • Un verbo (GET, PUT o HEAD) • La dirección del objeto requerido (parte de la URL que sigue a la dirección del servidor). • La versión del protocolo HTTP empleada (p.e., HTTP/1.0). • Un conjunto variable de información (datos sobre las capacidades del navegador, datos opcionales para el servidor, etc.) – El servidor devuelve la respuesta al cliente, constituida por: • Un código de estado. • El tipo de dato MIME de la información de retorno. • La información requerida. – Se cierra la conexión HTTP. • En la actualidad se ha mejorado este procedimiento, permitiendo que una misma conexión se mantenga activa durante un cierto periodo de tiempo, de forma que sea utilizada en sucesivas transacciones (HTTP Keep Alive). Página - 15 -
  • Costes de conexión • En HTTP 1.0, el servidor corta la conexión una vez enviados los datos • En HTTP 1.1, la conexión se mantiene activa durante un tiempo para permitir que el cliente siga haciendo peticiones (p.e. de las imágenes del documento) sin tener que establecer la conexión para cada una de ellas. • HTTP no guarda información de una transacción a otra, lo cual permite que un servidor sirva a más clientes a la vez. • La desventaja es que CGIs más complejos necesitan utilizar campos ocultos en formularios o cookies para guardar información sobre sesiones. Página - 16 -
  • El protocolo define además cómo codificar el paso de parámetros entre páginas, el tunelizar las conexiones (para sistemas de firewall), define la existencia de servidores intermedios de cache, etc. Métodos HTTP – Comandos que comienzan la primera línea de la solicitud de un cliente – Informan al servidor del propósito de la petición del cliente. – Existen 3 métodos principales: GET, HEAD y POST (deben ir en mayúsculas) Las directivas de petición de información que define HTTP 1.1 (la versión considerada estable y al uso) son: GET Petición de recurso. POST Petición de recurso pasando parámetros. HEAD Petición de datos sobre recurso. PUT Creación o envío de recurso. DELETE Eliminación de recurso. TRACE Devuelve al origen la petición tal como se ha recibido en el receptor, para depurar errores. OPTIONS Sirve para comprobar las capacidades del servidor. CONNECT Reservado para uso en servidores intermedios capaces de funcionar como túneles. Detallaremos a continuación algunos de estos comandos, ya que su comprensión es fundamental para el desarrollo de aplicaciones Web. Página - 17 -
  • Cabe destacar que todos los recursos que sean servidos mediante HTTP deberán ser referenciados mediante una URL (Universal Resource Locators). Página - 18 -
  • Peticiones en HTTP: GET y POST Las peticiones en HTTP pueden realizarse usando dos métodos. - El método GET, que se utiliza para recoger cualquier tipo de información del servidor (realizar peticiones) en caso de enviar parámetros junto a la petición, las enviaría codificadas en la URL. Se utiliza siempre que se pulsa sobre un enlace o se teclea directamente una URL. Como resultado, el servidor HTTP envía el documento correspondiente a la URL seleccionada, o bien activa un módulo CGI, que generará a su vez la información de retorno. - Por su parte, el método POST, en caso de enviarlos, lo haría como parte del cuerpo de la petición. (p.e., los datos contenidos en un formulario). El servidor pasará esta información a un proceso encargado de su tratamiento (generalmente una aplicación CGI). La operación que se realiza con la información proporcionada depende de la URL utilizada. Una petición GET sigue el siguiente formato: GET /index.html HTTP/1.1 Host: www.ejemplo.com User-Agent: Mozilla/4.5 [en] Accept: image/gif, image/jpeg, text/html Accept-language: en Accept-Charset: iso-8859-1 Página - 19 -
  • Podemos ver que está formada por: 1. Línea de petición: contiene el recurso solicitado. 2. Cabecera de petición: contiene información adicional sobre el cliente. 3. Cuerpo de petición: en las peticiones de tipo POST, y otras, contiene información adicional. • Línea de petición La línea de petición está formada por los siguientes elementos: 1. Método: nombre del método de HTTP llamado (GET, POST, etc.). 2. Identificador de recurso: URL (uniform resource locator) del recurso solicitado. 3. Versión de protocolo: versión del protocolo solicitada para la respuesta. • Cabecera de petición Contiene información adicional que puede ayudar al servidor (o a los servidores intermedios, los proxies y caches) a procesar adecuadamente la petición. La información se proporciona en forma de: Página - 20 -
  • Identificador: valor De estos identificadores, los más conocidos e importantes son: Host: nombre del servidor solicitado. User-Agent: nombre del navegador o programa usado para acceder al recurso. Accept: algunos formatos de texto e imagen aceptados por el cliente. Accept-Language: idiomas soportados (preferidos) por el cliente, útil para personalizar la respuesta automáticamente. • Parámetros de petición Una petición HTTP puede también contener parámetros, como respuesta, por ejemplo, a un formulario de registro, a una selección de producto en una tienda electrónica, etc. Estos parámetros pueden pasarse de dos formas: – Como parte de la cadena de petición, codificados como parte de la URL. – Como datos extra a la petición. Para codificar los parámetros como parte de la URL, éstos se añaden a la URL detrás del nombre del recurso, separados de éste por un carácter ?. Los diferentes parámetros se separan entre sí por el carácter &. Los espacios se sustituyen por +. Por último, los caracteres especiales (los mencionados Página - 21 -
  • antes de &, + y ?, así como los caracteres no imprimibles, etc.) se representan con %xx, donde xx representa al código ASCII en hexadecimal del carácter. Por ejemplo: http://www.ejemplo.com/indice.jsp?nombre=Perico+Palotes&OK=1 que en la petición HTTP quedaría: GET /indice.jsp?nombre=Perico+Palotes&OK=1 HTTP/1.0 Host: www.ejemplo.com User-Agent: Mozilla/4.5 [en] Accept: image/gif, image/jpeg, text/html Accept-language: en Accept-Charset: iso-8859-1 Para pasar los parámetros como datos extra de la petición, éstos se envían al servidor como cuerpo de mensaje en la petición. Por ejemplo, la petición anterior quedaría: POST /indice.jsp HTTP/1.0 Host: www.ejemplo.com User-Agent: Mozilla/4.5 [en] Accept: image/gif, image/jpeg, text/html Accept-language: en Accept-Charset: iso-8859-1 Página - 22 -
  • nombre=Perico+Palotes&OK=1 Cabe destacar que para pasar los parámetros como cuerpo de la petición, ésta debe realizarse como POST y no como GET, aunque una petición POST también puede llevar parámetros en la línea de petición. Los parámetros pasados como cuerpo de la petición están codificados, al igual que en el ejemplo anterior, como URL, o pueden usar una codificación derivada del formato MIME (multipurpose internet mail extensions), en lo que se conoce como codificación multiparte. Página - 23 -
  • La petición anterior en formato multiparte sería: POST /indice.jsp HTTP/1.0 Host: www.ejemplo.com User-Agent: Mozilla/4.5 [en] Accept: image/gif, image/jpeg, text/html Accept-language: en Accept-Charset: iso-8859-1 Content-Type: multipart/form-data, delimiter=“----ALEATORIO----” ----ALEATORIO---- Content-Disposition: form-data; name=“nombre” Perico Palotes ----ALEATORIO---- Content-Disposition: form-data; name=“OK” 1 ----ALEATORIO------ Esta codificación es exclusiva del método POST. Se emplea para enviar ficheros al servidor. Respuestas en HTTP Página - 24 -
  • Las respuestas en HTTP son muy similares a las peticiones. Una respuesta estándar a una petición de una página sería similar a lo siguiente: HTTP/1.1 200 OK Date: Mon, 04 Aug 2003 15:19:10 GMT Server: Apache/2.0.40 (Red Hat Linux) Last-Modified: Tue, 25 Mar 2003 08:52:53 GMT Accept-Ranges: bytes Content-Length: 428 Connection: close <HTML> ... En ella podemos observar que la primera línea nos responde con la versión del protocolo empleada para enviarnos la página, seguida de un código de retorno (código de estado) y una frase de retorno. El código de retorno puede adoptar uno de los siguientes valores: – 1xx Información. Petición recibida, continúa en proceso. – 2xx Petición Correcta. Petición procesada correctamente. – 3xx Petición Redirección. La petición debe repetirse o redirigirse. – 4xx Error de cliente. No se puede procesar la petición porque ésta es incorrecta, no existe, etc. – 5xx Error de servidor. El servidor ha fallado intentando procesar la petición, que a priori es correcta. Página - 25 -
  • Códigos de respuesta del Servidor • HTTP define algunos de valores en cada rango. El resto puede usarlos el servidor. • Si un cliente no entiende un código, puede ‘adivinar’ su significado por el rango en que se encuentra. • Los navegadores suelen mostrar los códigos de los rangos 400- y 500-, pero no el resto. Códigos de Información • 100 Continue el principio de la petición se ha recibido, y el cliente puede continuar con la petición. • 101 Switching Protocols el servidor acepta cambiar a un protocolo solicitado por el cliente. Códigos de Petición Correcta • 200 OK envío de los datos solicitados. • 201 Created se ha creado un URI y se envía su dirección. • 202 Accepted Petición aceptada pero no procesada. Puede que no se procese. • 203 Non-Authoritative Information la información viene de terceros, no del servidor. • 204 No Content Respuesta sin cuerpo. • 205 Reset Content Vaciar un formulario para que se puedan introducir más datos. • 206 Partial Content El servidor devuelve una parte de una página del tamaño solicitado. También indica qué parte de la página es. Página - 26 -
  • Códigos de Redirección • 300 Multiple Choices el URI de la petición hace referencia a más de un documento. • 301 Moved Permanently el URI de la petición ya no es de ese servidor. Se devuelve la nueva dirección. • 302 Moved Temporarily el URI se ha trasladado temporalmente. • 303 See Other el documento solicitado se puede encontrar en otro URI, y se debe solicitar en él. • 304 Not Modified indica que un URI no se ha modificado y se puede usar la copia local. • 305 Use Proxy se debe acceder al URI a través del proxy que se indica. Códigos de Error de Cliente • 400 Bad Request error sintáctico en la petición. • 401 Unauthorized se debe proporcionar una autentificación correcta. • 402 Payment Required sin implementar. • 403 Forbidden acceso prohibido por una razón que el servidor no quiere o no puede especificar. • 404 Not Found el documento no existe. • 405 Method Not Allowed el método usado por el cliente no funciona en ese URI. • 406 Not Acceptable el URI existe, pero no con el formato aceptado por el cliente. • 407 Proxy Authentication Required el proxy necesita autorizar la petición antes de enviarla. • 408 Request Time-out la petición no se ha terminado en un tiempo predeterminado. Página - 27 -
  • • 409 Conflict la petición está en conflicto con otra o con la configuración del servidor. • 410 Gone el URI no existe y ha sido eliminado permanentemente del servidor. • 411 Length Required no se acepta la petición si no se proporciona su longitud. • 412 Precondition Failed no se cumple una condición de la cabecera de la petición. • 413 Request Entity Too Large el cuerpo de la petición es demasiado grande. • 414 Request-URI Too Long el URI de la petición es demasiado largo. • 415 Unsupported Media Type el cuerpo de la petición tiene un formato desconocido. Página - 28 -
  • Códigos de Error de Servidor • 500 Internal Server Error una parte del servidor (o un CGI) no funciona y no puede servir la petición. • 501 Not Implemented la petición realizada no puede ser llevada a cabo por el servidor. • 502 Bad Gateway el servidor o el Proxy recibieron un error de otro servidor o proxy. • 503 Service Unavailable el servicio está temporalmente fuera de servicio. • 504 Gateway Time-out como el error 408 pero es el gateway o el proxy quien produce el error. • 505 HTTP Version not supported el servidor no tiene implementada esa versión de HTTP. La frase de retorno dependerá de la implementación, pero sólo sirve como aclaratorio del código de retorno. Después del estatus aparece una serie de campos de control, con el mismo formato que en las cabeceras de la petición que nos informan del contenido (fecha de creación, longitud, versión del servidor, etc.). Página - 29 -
  • Comandos adicionales de HTTP/1.1 (RFC 2068) – HEAD permite solicita información sobre un objeto (fichero): tamaño, tipo, fecha de modificación. • Es utilizado por los gestores de cachés de páginas o los servidores proxy, para conocer cuándo es necesario actualizar la copia que se mantiene de un fichero. – PUT permite actualizar información sobre un objeto del servidor. • Es similar a POST, pero en este caso, la información enviada al servidor debe almacenarse en la URL que acompaña al comando. – DELETE permite eliminar el documento especificado del servidor. – LINK que crea una relación entre documentos. – UNLINK que elimina una relación existente entre documentos del servidor. – OPTIONS retorna las opciones del servidor. Cabeceras comunes para peticiones y respuestas – Content-Type • Descripción MIME de la información contenida en este mensaje. Es la referencia que utilizan las aplicaciones Web para tratar correctamente los datos que reciben. – Content-Length • Longitud en bytes de los datos enviados, expresados en base decimal. – Content-Encoding Página - 30 -
  • • Formato de codificación de los datos enviados en este mensaje. Permite, por ejemplo, enviar datos comprimidos (x-gzip o x-compress) o encriptados. – Date • Fecha local de la operación, que debe incluir la zona horaria en que reside el sistema que genera la operación. – Pragma • Permite incluir información variada relacionada con el protocolo HTTP en el requerimiento o respuesta que se está realizando. Cabeceras para peticiones del cliente – Accept: campo opcional que contiene una lista de tipos MIME aceptados por el cliente. • Se pueden utilizar * para indicar rangos de tipos de datos; tipo/* indica todos los subtipos de un determinado medio, mientras que */* representa a cualquier tipo de dato disponible. – Authorization: clave de acceso que envía un cliente para acceder a un recurso de uso protegido o limitado. – From: campo opcional que contiene la dirección de correo electrónico del usuario del cliente Web que realiza el acceso. – If-Modified-Since: permite realizar operaciones GET condicionales, en función de si la fecha de modificación del objeto requerido es anterior o posterior a la fecha proporcionada. – Referer: contiene la URL del documento desde donde se ha activado este enlace. Página - 31 -
  • – User-agent: cadena que identifica el tipo y versión del cliente que realiza la petición. Cabeceras para respuestas del servidor – Allow: informa de los comandos HTTP opcionales que se pueden aplicar sobre el objeto al que se refiere esta respuesta. – Expires: fecha de expiración del objeto enviado. – Last-modified: fecha local de modificación del objeto devuelto. – Location: uri informa sobre la dirección exacta del recurso al que se ha accedido. – Server: cadena que identifica el tipo y versión del servidor HTTP. – WWW-Autenticate: cuando se accede a un recurso protegido o de acceso restringido, el servidor devuelve un código de estado 401, y utiliza este campo. – Content-Base: uri URI base para resolver direcciones relativas – Content-Language: en, fr, sp lenguaje en el que va el cuerpo del mensaje – Content-Type: image/jpg tipo de contenido que se transfiere. Si lo transmite el servidor, debe estar en consonancia con lo que especificó el cliente con la cabecera Accept – URI: uri nueva localización de un documento. Acompaña a los códigos de servidor 201 (Created), 301 (Moved Permanently), o 302 (Moved Temporarily). Está en desuso. Página - 32 -
  • Tipos y Subtipos de Contenido • Se usan para comunicar el formato del contenido de una transacción HTTP. • Los clientes los usan en la cabecera Accept para indicarle al servidor los formatos en los que pueden recibir datos. • Los servidores los usan con la cabecera Content-Type para indicar cuál es el contenido del mensaje. • Son muy similares a los tipos MIME (Multipurpose Internet Mail Extension). • Llevan el formato tipo/subtipo. • Los servidores y CGIs deben examinar los tipos incluidos en la cabecera Accept y enviar datos de ese tipo siempre que sea posible. Algunos tipos y subtipos comunes: Página - 33 - application/pdf application/postscript application/rtf image/gif image/jpeg text/html text/plain video/mpeg pdf ai, eps, ps rtf gif jpeg, jpg, jpe html, htm txt mpeg, mpg, mpe
  • Página - 34 -
  • Persistencia en http –Cookies. Las cookies son una de las incorporaciones más recientes al protocolo HTTP, y son parte del nuevo estándar HTTP/1.1. Las cookies son pequeños ficheros de texto que se intercambian los clientes y servidores HTPP, para solucionar una de las principales deficiencias del protocolo: la falta de información de estado entre dos transacciones. Fueron introducidas por Netscape, y ahora han sido estandarizadas en el RFC 2109. Cada intercambio de información con un servidor es completamente independiente del resto, por lo que las aplicaciones CGI que necesitan recordar operaciones previas de un usuario (por ejemplo, los supermercados electrónicos) pueden optar por dos soluciones, que complican bastante su diseño: almacenar temporalmente en el sistema del servidor un registro de las operaciones realizadas, con una determinada política para eliminarlas cuando no son necesarias, o bien incluir esta información en el código HTML devuelto al cliente, como campos HIDDEN de un formulario. Las cookies son una solución más flexible a este problema. La primera vez que un usuario accede a un determinado documento de un servidor, éste proporciona una cookie que contiene datos que relacionarán posteriores operaciones. El cliente almacena la cookie en su sistema para usarla después. En los futuros accesos a este servidor, el navegador podrá proporcionar la cookie original, que servirá de nexo entre este acceso y los anteriores. Todo este proceso se realiza automáticamente, sin intervención del usuario. El problema de las cookies es que por cuestiones de seguridad los clientes pueden tenerlas desactivadas. Una alternativa a las cookies que resuelve este problema son las variables de sesión. Éstas son variables de servidor que almacenan sus valores (su estado) en tanto el navegador Página - 35 -
  • permanece abierto en el cliente (o durante un cierto tiempo). En este caso también se utilizan pequeños ficheros de texto pero, a diferencia del caso anterior, no se intercambian y residen en el servidor. Página - 36 -