Protocolo http y WWW

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
Accept-language: en
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
Accept-language: en
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
Accept-language: en
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

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 -

Protocolo http y WWW

Más contenido relacionado

La actualidad más candente

Destacado

Similar a Protocolo http y WWW

Protocolo http y WWW