Unidad 4

Unidad 4

SERVIDOR WEB

1 de 31
Unidad 4

Objetivos

Objetivos

Cuando finalices este tema habrás a aprendido a...

Administrar servidores Web aplicando criterios de configuración y asegurando el funcionamiento

del servicio.
Instalar y configurar un servidor Web en diferentes sistemas operativos y con diferentes
configuraciones.

2 de 31
Unidad 4

Conocimiento Previo

Conocimiento previo

Necesitas tener los siguientes conocimientos:

Saber utilizar un navegador web a nivel de usuario.

Conocimientos básicos de redes.
Estar familiarizado con el interfaz terminal en Gnu/Linux.
Estar familiarizado con un entorno Windows Server.

3 de 31
Unidad 4

Motivación

Hoy en día, el servicio web está muy extendido en la sociedad. Ya forma parte de la rutina diaria de todos
nosotros tanto a nivel personal como a nivel profesional.

Toda empresa que se precie, sea pequeña o grande, tiene un escaparate en Internet.

A nivel personal, mucha gente dispone de blog, página web, álbum de fotos, perfil en alguna red social, etc.
Además, y cada vez con más frecuencia, recurrimos a todo tipo de servicios en Internet: banca online, búsquedas
y consulta de información, gestiones de la administración pública, lectura de periódicos, revistas, correo web,
compras, ... y un largo etcétera de tareas que ya se han transformado en habituales.
Pero, ¿dónde están alojadas estas páginas? ¿Qué hay detrás de ellas? ¿Qué servicio las pone a nuestra
disposición y cómo funciona?
A lo largo de este tema vamos estudiar y entender estas y otras cuestiones. Además, vamos a aprender a
instalar y configurar las herramientas que nos permiten ofrecer un servicio web (servicio HTTP).

4 de 31
Unidad 4

Introducción

Las siglas HTTP corresponden al Protocolo de Transferencia de HiperTexto (Hypertext Transfer Protocol). Se
trata de un sencillo protocolo cliente-servidor que articula los intercambios de información entre los clientes Web
(navegadores) y los servidores HTTP

Fue creado inicialmente en el 1990 en el CERN (laboratorio europeo de física de la partículas) como medio para
compartir datos científicos a escala internacional de una manera rápida y con un coste moderado. Actualmente,
es el método más común de intercambio y compartición de información en la WWW (World Wide Web).

El propósito del protocolo HTTP es permitir la transferencia de archivos (principalmente, en formato HTML). entre
un navegador (el cliente) y un servidor web localizado mediante una cadena de caracteres denominada dirección
URL (Uniform Resource Locator)

El concepto de hipertexto hace referencia al tipo de contenido que se ofrece en las páginas web (texto enlazado
que permite saltar de un lugar a otro).

En la actualidad, gran parte de las aplicaciones software (ya sean de gestión, consulta, ofimática, formación,
entretenimiento, comercio electrónico, etc) son aplicaciones web que los usuarios pueden utilizar mediante
navegadores para acceder a los servidores web donde se alojan, ya sea en redes públicas (Internet) o privadas
(Intranets).

El servicio HTTP es el pilar sobre el que se construye todo este entramado que hace posible la
intercomunicación a escala mundial.

Existe una versión segura de HTTP llamada HTTPS que permite el uso de cualquier método de cifrado siempre
que lo compartan el servidor y el cliente.

El protocolo

El protocolo de transferencia es el conjunto de normas mediante las cuales se envían peticiones de acceso a una
web y la consiguiente respuesta.

5 de 31
Unidad 4

La versión actual del protocolo es la 1.1 (ver RFC en recursos del tema)

Los propios creadores del HTTP 1.1 describen el protocolo como:

Un protocolo de nivel de aplicación orientado a sistemas distribuidos, para la colaboración e

hypermedia. Un protocolo genérico, sin estado, orientado a objetos y que puede ser utilizado para
muchas aplicaciones, como servidores de nombres y sistemas de gestión de objetos distribuidos, a
través de las extensiones de los métodos de petición. Una característica de este protocolo es la
negociación de los tipos y representación de los datos, permitiendo que los sistemas no dependan
del tipo de datos que se utilicen

6 de 31
Unidad 4

Desde el punto de vista de las comunicaciones, el protocolo está soportado sobre los servicios de conexión
TCP/IP: 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.

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. Los recursos pueden ser archivos, el
resultado de la ejecución de un programa, una consulta a una base de datos, la traducción automática de un
documento, etc.

HTTP es un protocolo sin estado, es decir, que no guarda ninguna información sobre conexiones anteriores. El
desarrollo de aplicaciones web necesita frecuentemente mantener estado. Para esto se usan las cookies, que es
información que un servidor puede almacenar en el sistema cliente. Esto le permite a las aplicaciones web instituir
la noción de "sesión".

Actividad

¿Sabrías nombrar al menos 4 productos o implementaciones diferentes del servicio Web?

¿Cuál es la implementación más utilizada en todo el mundo? ¿Cuántos servidores la utilizan?
Puedes consultar la siguiente página para obtener la respuesta: http://news.netcraft.com/

7 de 31
Unidad 4

Funcionamiento

Ya hemos comentado que el protocolo HTTP tiene un funcionamiento bastante sencillo basado en el envío de
mensajes entre cliente y servidor.

Gráficamente podemos resumir el proceso de comunicación HTTP como sigue:

1. Un usuario accede a una URL, seleccionando un enlace de un documento HTML o introduciéndola

directamente en el campo Location del cliente Web.
2. El cliente Web descodifica la URL, separando sus diferentes partes: el protocolo de acceso, la dirección
DNS o IP del servidor, el posible puerto opcional (el valor por defecto es 80) y el objeto requerido del
servidor.
http://direccion[:puerto][path]
Ejemplo: http://www.miweb.com/documento.html
3. Se abre una conexión TCP/IP con el servidor, llamando al puerto TCP correspondiente. En ese momento,
se realiza la petición HTTP.
Para ello, se envía el comando necesario (GET, POST, HEAD,...), la dirección del objeto requerido (el
contenido de la URL que sigue a la dirección del servidor), la versión del protocolo HTTP empleada (casi
siempre HTTP/1.0) y un conjunto variables de información, que incluye datos sobre las capacidades del
navegador (browser), datos opcionales para el servidor, etc.
4. El servidor devuelve la respuesta al cliente.
Consiste en un código de estado y el tipo de dato MIME de la información de retorno, seguido de la
propia información.
5. Se cierra la conexiónTCP.

Este proceso se repite en cada acceso al servidor HTTP.

Por ejemplo, si se recoge un documento HTML en cuyo interior están insertadas 2 imágenes y 1 vídeo, el proceso
anterior se repite cuatro veces, una para el documento HTML y tres más para los recursos (la dos imágenes y el
vídeo).

Comandos del protocolo

El estándar HTTP/1.0 recoge únicamente tres comandos, que representan las operaciones de recepción y envío
de información y chequeo de estado:

GET: se utiliza para solicitar cualquier tipo de información o recurso al servidor. Cada vez que se pulsa
sobre un enlace o se teclea directamente a una URL se usa este comando.. Como resultado, el servidor
HTTP enviará el recurso correspondiente.

HEAD: se utiliza para solicitar información sobre el recurso: su tamaño, su tipo, su fecha de
modificación… Es usado por los gestores de cachés de páginas o los servidores proxy, para conocer

8 de 31
Unidad 4

cuándo es necesario actualizar la copia que se mantiene del recurso.

También puede ser usado por el propio cliente Web que mantiene un caché de páginas recientemente
visitadas. Con HEAD podrá comprobar la última fecha de modificación de un recurso antes de traer una
nueva copia del mismo.

POST: sirve para enviar información al servidor, por ejemplo, los datos contenidos en un formulario. El
servidor pasará esta información a un proceso encargado de su tratamiento (por ejemplo, una aplicación
CGI). La operación que se realiza con la información proporcionada depende de la URL utilizada. Se
utiliza, sobre todo, en los formularios.

La versión 1.1 del protocolo incorpora unos pocos comandos más como son: OPTIONS, PUT, DELETE, TRACE y
CONNECT. Veamos algunos de ellos:

OPTIONS: este comando permite conocer las características de conexión entre nuestro cliente y el
servidor. Podemos utilizarlo para realizar saber si el servidor responde o no.
DELETE: sirve para eliminar un recurso especificado en la URL, aunque pocas veces sera permitido por
un servidor web.
TRACE: comando que permite hacer un sondeo para saber todos los dispositivos de la red por los que
pasa nuestra petición. Así podremos descubrir si la petición pasa a través dispositivos intermedios o
proxys antes de llegar al servidor Web.
PUT: puede verse como el comando inverso a GET. Nos permite escribir datos en el servidor o, lo que es
lo mismo, poner un recurso en la URL que se especifique. Si el recurso no existe lo crea sino lo
reemplaza.
La diferencia con POST puede ser algo confusa. POST simplemente envía una información al servidor
para que éste la trate como considere oportuno. La URL que se especifica en un POST es el recurso al
que se le enviarán los datos y será el encargado de tratarlos.
Más información sobre la diferencia entre POST y PUT: http://notasjs.blogspot.com.es/2013/07/http-
diferencia-entre-post-y-put.html

Solicitud
Una solicitud HTTP es un conjunto de líneas que el navegador envía al servidor. Incluye:

El recurso solicitado, el método que se aplicará y la versión del protocolo utilizada (por lo general,
HTTP/1.0).
Los campos del encabezado de solicitud: es un conjunto de líneas opcionales que permiten aportar
información adicional sobre la solicitud y/o el cliente (navegador, sistema operativo, etc.). Cada una de
estas líneas está formada por un nombre que describe el tipo de encabezado, seguido de dos puntos (:) y
el valor del encabezado.
El cuerpo de la solicitud: es un conjunto de líneas opcionales que deben estar separadas de las líneas
precedentes por una línea en blanco y que, por ejemplo, permiten la transmisión de datos al servidor de un
formulario a través del método POST.

Un ejemplo de una solicitud podría ser:

GET http://www.cippbatoi.es HTTP/1.0 Accept : Text/html If-Modified-Since

: Saturday, 15-January-2010 14:37:11 GMT
User-Agent : Mozilla/5.0 (Windows NT 5.1; rv:23.0) Gecko/20100101
Firefox/23.0

Respuesta

La sintaxis de una respuesta HTTP es un conjunto de líneas que el servidor envía al navegador. Incluye:

9 de 31
Unidad 4

Una línea de estado donde figura el versión del protocolo usada, un código de estado/error y un texto
con el significado de dicho código.
Los posibles códigos de estado se identifican con números de tres cifras y se clasifican en cinco grupos
según sean informativos (1xx), de éxito en la solicitud (2xx), para redireccionar la solicitud (3xx), por error
generado en el cliente (4xx) o bien por errores generados en el servidor (5xx).
Ejemplo.- Son respuestas típicas los códigos 200, para indicar OK de la petición, y el 404, para indicar que
el objeto solicitado no está disponible.

Los campos del encabezado de la respuesta. Conjunto de lineas opcionales que aportan información
adicional sobre la respuesta y/o el servidor.
El cuerpo de la respuesta que contiene el recurso (objeto) solicitado.

Ejemplo de una respuesta podría ser:

HTTP/1.0 200 OK Date: Sat, 15 Jan 2010 14:37:12 GMT Server : Microsoft-
IIS/2.0 Content-Type : text/HTML Content-Length : 1245
Last-Modified : Fri, 14 Jan 2010 18:11:12 GMT

Códigos de estado/error

Código Mensaje Descripción

Mensaje de
10x Estos códigos no se utilizan en la versión 1.0 del protocolo
información
20x Éxito Estos códigos indican la correcta ejecución de la transacción
200 OK La solicitud se llevó a cabo de manera correcta
Sigue a un comando POST e indica el éxito, la parte restante del
201 CREATED cuerpo indica la dirección URL donde se ubicará el documento creado
recientemente.
La solicitud ha sido aceptada, pero el procedimiento que sigue no se
202 ACCEPTED
ha llevado a cabo
PARTIAL Cuando se recibe este código en respuesta a un comando de GET
203
INFORMATION indica que la respuesta no está completa.
El servidor ha recibido la solicitud, pero no hay información de
204 NO RESPONSE
respuesta
El servidor le indica al navegador que borre el contenido en los campos
205 RESET CONTENT
de un formulario
PARTIAL Es una respuesta a una solicitud que consiste en el encabezado range.
206
CONTENT El servidor debe indicar el encabezado content-Range
Estos códigos indican que el recurso ya no se encuentra en la
30x Redirección
ubicación especificada
301 MOVED Los datos solicitados han sido transferidos a una nueva dirección
Los datos solicitados se encuentran en una nueva dirección URL, pero,
302 FOUND
no obstante, pueden haber sido trasladados
Significa que el cliente debe intentarlo con una nueva dirección; es
303 METHOD
preferible que intente con otro método en vez de GET
Si el cliente llevó a cabo un comando GET condicional (con la solicitud
relativa a si el documento ha sido modificado desde la última vez) y el
304 NOT MODIFIED
documento no ha sido modificado, este código se envía como

10 de 31
Unidad 4

respuesta.
Error debido al
40x Estos códigos indican que la solicitud es incorrecta
cliente
La sintaxis de la solicitud se encuentra formulada de manera errónea o
400 BAD REQUEST
es imposible de responder
Los parámetros del mensaje aportan las especificaciones de
401 UNAUTHORIZED formularios de autorización que se admiten. El cliente debe reformular
la solicitud con los datos de autorización correctos
PAYMENT
402 El cliente debe reformular la solicitud con los datos de pago correctos
REQUIRED
403 FORBIDDEN El acceso al recurso simplemente se deniega
Un clásico. El servidor no halló nada en la dirección especificada. Se
404 NOT FOUND
ha abandonado sin dejar una dirección para redireccionar... :)

Error debido al
50x Estos códigos indican que existe un error interno en el servidor
servidor

El servidor encontró una condición inesperada que le impide seguir con

500 INTERNAL ERROR
la solicitud (una de esas cosas que les suceden a los servidores...)
NOT
501 El servidor no admite el servicio solicitado (no puede saberlo todo...)
IMPLEMENTED
El servidor que actúa como una puerta de enlace o proxy ha recibido
502 BAD GATEWAY
una respuesta no válida del servidor al que intenta acceder
El servidor no puede responder en ese momento debido a que se
SERVICE
503 encuentra congestionado (todas las líneas de comunicación se
UNAVAILABLE
encuentran congestionadas, inténtelo de nuevo más adelante)
La respuesta del servidor ha llevado demasiado tiempo en relación al
GATEWAY
504 tiempo de espera que la puerta de enlace podía admitir (excedió el
TIMEOUT
tiempo asignado...)

Encabezados HTTP

Los encabezados (lineas de encabezados) de los mensajes constituyen un elemento fundamental en el protocolo
ya que definen gran parte de la información que se intercambia entre clientes y servidores, dándole así mucha
flexibilidad.

Estas líneas permiten que se envíe información descriptiva en la propia transacción, permitiendo, por ejemplo, la
autenticación o identificación de usuarios.
La sintaxis de una línea simple de encabezado se compone del nombre de encabezado, seguido de dos puntos
y el valor correspondiente.

Los encabezados pueden clasificarse en los siguientes grupos según su función:

De ámbito general: manejan información que puede ser utilizada tanto por clientes como por servidores,
ya que se aplican a una sesión completa de comunicación
De solicitud: los utiliza el cliente para enviar información adicional al servidor, en sus peticiones de algún
servicio.
De respuesta: utilizados por el servidor para enviar información añadida al cliente.
De entidad: con información relaciona directamente con el recurso que se le va a proporcionar al cliente.

11 de 31
Unidad 4

En el siguiente enlace podemos ver una lista completa de los encabezados: https://en.wikipedia.org
/wiki/List_of_HTTP_header_fields

Veamos aquí algunos de ellos.

Petición

Cada petición a un servidor web lleva campos adicionales para poder personalizarla. Estos se escriben linea por
linea después de conectar y permiten indicar al servidor, entre otras cosas, los tipos de archivos que aceptamos,
el lenguaje, sistemas de codificación, etc.

Estos son algunos de los encabezados de petición más importantes con su descripción:

Nombre del
Descripción
encabezado
Tipo de contenido aceptado por el navegador (por ejemplo, texto/html). Ver
Accept
tipos MIME
Accept-Charset Juego de caracteres que el navegador espera
Accept-Encoding Codificación de datos que el navegador acepta
Accept-Language Idioma que el navegador espera (de forma predeterminada, inglés)
Authorization Identificación del navegador en el servidor
Content-Encoding Tipo de codificación para el cuerpo de la solicitud
Content-Language Tipo de idioma en el cuerpo de la solicitud
Content-Length Extensión del cuerpo de la solicitud
Tipo de contenido del cuerpo de la solicitud (por ejemplo, texto/html). Ver tipos
Content-Type
MIME.
Date Fecha en que comienza la transferencia de datos
Forwarded Utilizado por equipos intermediarios entre el navegador y el servidor
From Permite especificar la dirección de correo electrónico del cliente
Permite especificar que debe enviarse el documento si ha sido modificado
From
desde una fecha en particular
Link Vínculo entre dos direcciones URL
Orig-URL Dirección URL donde se originó la solicitud
Referer Dirección URL desde la cual se realizó la solicitud
Cadena con información sobre el cliente, por ejemplo, el nombre y la versión
User-Agent
del navegador y el sistema operativo

Respuesta

Estos son algunos de los encabezados de respuesta más comunes junto con una breve descripción.

Nombre del
Descripción
encabezado
Content-Encoding Tipo de codificación para el cuerpo de la respuesta
Content-Language Tipo de idioma en el cuerpo de la respuesta
Content-Length Extensión del cuerpo de la respuesta

12 de 31
Unidad 4

Tipo de contenido del cuerpo de la respuesta (por ejemplo, texto/html). Ver

Content-Type
Tipos MIME.
Date Fecha en que comienza la transferencia de datos
Expires Fecha límite de uso de los datos
Forwarded Utilizado por equipos intermediarios entre el navegador y el servidor
Location Redireccionamiento a una nueva dirección URL asociada con el documento
Server Características del servidor que envió la respuesta

Ejemplos de comunicación HTTP

Vamos a hacer uso del comando TELNET para realizar una conexión a un servidor Web. Usando esa conexión
vamos a lanzar una serie de comandos para ver su funcionamiento y así, entender mejor todo el proceso.

Los pasos a seguir son los siguientes:

1. Desde un terminal (en nuestro caso un Bash de Gnu/Linux), hacemos el TELNET correspondiente y
verificamos que realiza la conexión (Connected to ...).
No hay que olvidar especificar la web destino (en nuestro ejemplo: www.mec.es) y el puerto de escucha
80.
2. Si todo ha ido bien, tendremos una sesión abierta para comunicarnos con el servidor Web.
3. A partir de ese momento, podemos escribir los comandos que queramos y observar la respuesta del
servidor.
No hay que olvidar que, después de cada comando, hay que pulsar dos veces ENTER para que el
mensaje se envíe.

Utilizando GET

Comando: GET /index.html HTTP/1.0

Observa la respuesta del servidor: el código de estado 200 OK, el servidor, la fecha, etc. y, finalmente, el
contenido de la web (la página HTML que visualizará el navegador).

Utilizando HEAD

Comando: HEAD /index.html HTTP/1.0

13 de 31
Unidad 4

En este caso, dado que con HEAD estamos pidiendo información sobre el recurso, solo se nos envían las lineas
de respuesta correspondientes, sin la página HTML.

Utilizando OPTIONS

Comando: OPTIONS * HTTP/1.1

Linea adicional: Host: www.mec.es

El * indica que queremos información sobre el servidor en general y no sobre un recurso en concreto.

En este caso, estamos pasando además del comando OPTIONS una linea adicional con el campo Host. Si
usamos HTTP/1.1 esta linea es necesaria (algunos servidores dan servicio a varios sitios web y, por tanto, seria
necesaria dicha linea). Hay que tener en cuenta que el doble ENTER no se realizará hasta que acabemos de
escribir todos los campos. En nuestro caso, justo después de Host.

14 de 31
Unidad 4

Observa la información que devuelve el comando OPTIONS. Entre otras cosas, devuelve los métodos soportados
por el servidor.

Actividad

Realiza diferentes conexiones a sitios web que conozcas mediante TELNET. Usa diferentes
métodos y observa la respuesta del servidor.
Solicita un recurso que no exista a un servidor web y observa el código de error que devuelve.
¿Cuál es?

Tipos MIME

El protocolo HTTP fue diseñado para transportar por red ficheros en formato ASCII, formados por texto plano. Con
el paso del tiempo, surgió la necesidad de incluir diferentes tipos de ficheros no ASCII en las aplicaciones por
Internet (imágenes, vídeos, sonidos, etc.) y, como consecuencia de ello, fue necesario buscar una solución: había
que transformar estos formatos a tipo ASCII (u otros juegos de caracteres compatibles) para su correcta
recepción en el navegador web.

Este problema ya había surgido en las aplicaciones de correo electrónico, cuando se necesitó enviar por MAIL
ficheros no formados por texto plano, y por tanto, no compatibles con los juegos de caracteres permitidos.
Para solucionar este problema el Internet Engineering Task Force (IETF) creó en 1992 los tipos MIME
(Multipurpose Internet Mail Extensions), especificaciones para dar formato a mensajes no-ASCII, de forma que
pudieran ser enviados por Internet e interpretados correctamente por los programas de correo locales.

Los tipos MIME permiten especificar los tipos de datos, como por ejemplo texto, imagen, audio, etc., que los
archivos contienen. MIME adjunta a cada fichero un archivo de cabecera donde se indica el tipo y el subtipo del
contenido de los datos del mismo. Gracias a esta información, tanto el servidor como el navegador pueden
manejar y presentar los archivos correctamente.

Un tipo MIME está formado de la siguiente manera:

Content-type: tipo_mime_principal/subtipo_mime.

Ejemplo: Content-type: image/gif

Tipos MIME primarios

Se usan para clasificar la larga lista de tipos MIME que existe. Los tipos de datos primarios, a veces denominados
"tipos de datos discretos", son:

texto: texto de datos legible. Ejemplo: text/plain, text/html, etc.

imagen: datos binarios que representan imágenes digitales. Ejemplo: image/jpeg, image/gif, etc.
audio: datos de sonido digital. Ejemplo: audio/basic, audio/wav, etc.
video: datos de vídeo. Ejemplo: video/mpeg, etc.
aplicación: Otros datos binarios. Ejemplo: application/octet-stream, application/pdf, etc.

Lista de tipos

En la tabla siguiente aparece un resumen de los tipos MIME más importantes.

15 de 31
Unidad 4

Tipo de MIME Tipo de archivo Extensión asociada

application/atom+xml Archivos en formato ATOM atom

application/iges Archivos CAS iges

application/javascript Archivos JavaScript js

application/dxf Archivos AutoCAD dxf

application/mp4 Archivos MPEG4 mp4

application/iges Formato de intercambio IGES CAD igs, iges

application/octet-stream Archivos binarios no interpretados bin

application/msword Archivos de documentos Microsoft Word doc

application/pdf Archivos Adobe Acrobat pdf

application/postscript Archivos PostScript ai, eps, ps

application/rtf Formato de texto enriquecido rtf

application/sgml Archivos SGML sgml

application/vnd.ms-excel Archivos de hojas de cálculo Microsoft Excel xls

application/vnd.ms-powerpoint Archivos de presentación Microsoft Powerpoint ppt

application/xml Archivo XML xml

application/x-tar Archivos TAR comprimidos tar

application/zip Archivos ZIP comprimidos man

audio/basic Archivos de audio básicos au, snd

audio/mpeg Archivo de audio MPEG mpg,mp3

audio/mp4 Archivo de audio MPEG-4 mp4

audio/x-aiff Archivos de audio AIFF aif, aiff, aifc

audio/x-wav Archivos de audio Wav wav

image/gif Imágenes Gif man

image/jpeg ?Imágenes Jpeg jpg, jpeg, jpe

imagen/png Imágenes PNG png

image/tiff ?Imágenes Tiff tiff, tif

image/x-portable-bitmap Archivos Bitmap PBM pbm

image/x-portable-graymap Archivos Graymap PBM pgm

image/x-portable-pixmap Archivos Pixmap PBM ppm

multipart/x-zip Archivos comprimidos en Zip zip

multipart/x-gzip Archivos comprimidos en Zip GNU gz, gzip

text/css Hoja de estilo css

text/csv Archivos de texto separados por comas csv

text/html Archivos HTML htm, html

text/plain Archivos de texto sin formato txt, g, h, c, cc, hh, m, f90

text/richtext Archivos de texto enriquecido rtx

text/rtf Archivos de texto con formato enriquecido rtf

16 de 31
Unidad 4

text/tab-separated-value Archivos de texto separados por tabulador tsv

text/xml Archivos XML xml

video/h264 Vídeos H.264 h264

video/dv Vídeos DV dv

video/mpeg Vídeos MPEG mpeg, mpg, mpe

video/quicktime Vídeos QuickTime qt, mov

video/msvideo Vídeos Microsoft Windows avi

Se puede consultar una lista completa en la web del organismo IANA:

http://www.iana.org/assignments/media-types/media-types.xhtml

Hay que tener en cuenta que si en el código HTML existen referencias a ficheros especiales cuyo tipo MIME no
está declarado previamente en el sistema local del usuario, el navegador web no será capaz de interpretar dicho
fichero (desconocerá qué hacer)

Los navegadores web traen configurados una serie de tipos MIME por defecto con los que sabrán trabajar sin
problema. Es el caso de, por ejemplo, las imágenes GIF o JPG. Para ello, el navegador mantiene en una base de
datos interna los tríos "extensión fichero" - "tipo MIME" - "aplicación necesaria". Si el navegador recibe un fichero
especial consultarà en dicha base datos qué debe hacer con ese tipo de contenido y realizará la acción que
corresponda. Si no lo encuentra, mostrará generalmente un mensaje de aviso o error al usuario.

Podemos ampliar la lista de extensiones MIME soportados por nuestro sistema. Este podría ser el caso de los
tipos MIME para cargar ficheros PDF o contenido FLASH que, por defecto, no vienen configurados.
Cuando instalamos un nuevo tipo éste será registrado en la base de datos del navegador y se asociará a un tipo
concreto de extensión de fichero, de forma que, cuando vayamos a abrir uno de los ficheros asociados a dicha
aplicación, el navegador ya sabrá cómo interpretar el fichero y qué aplicación debe llamar para su ejecución.

¿Es posible saber qué tipos MIME soporta nuestro navegador? Por ejemplo, para el caso de Firefox se pueden
consultar accediendo a la dirección about:plugins.

Otro tema a tener en cuenta a la hora de hablar de tipos MIME es que el servidor web en el que se aloje la página
web debe tener también configuradas las extensiones MIME adecuadas, ya que si no, no sabrá el tipo de datos
que le estamos pidiendo, por lo que no podrá enviarlo adecuadamente.

Puedes revisar las extensiones que soporta el sistema de tu ordenador accediendo al archivo
/etc/mime.types en el caso de los sistemas Gnu/Linux basados en Debian. Estas extensiones son las que
recogerá y soportará el servidor web que instalemos en dicho equipo.

$ cat /etc/mime.types
application/http
application/vnd.httphone
application/x-httpd-eruby rhtml

17 de 31
Unidad 4

application/x-httpd-php phtml pht php

application/x-httpd-php-source phps
application/x-httpd-php3 php3
...

Clientes y Servidores Web

Clientes

El cliente o navegador Web es una aplicación que permite visualizar páginas web alojadas en servidores Web
mostrando el contenido de la página en pantalla y, si la página lo permite, interactuar con ella o navegar a través
de enlaces a otra páginas web.

Un cliente web puede visualizar todo tipo de recursos básicos: texto, imágenes, vídeos, etc. Como ya se ha
comentado anteriormente con los tipos MIME es posible visualizar otros tipos diferentes de contenidos, siempre y
cuando, el navegador esté preparado para ello. Se le pueden añadir complementos que den al navegador
mayores capacidades de visualización. Por ejemplo, un navegador no sabrá visualizar un documento PDF pero si
le instalamos el complemento adecuado ya podrá hacerlo.
Además de visualizar contenidos en sus diferentes formas, tambié es posible ejecutar determinadas aplicaciones
que permitirán aumentar la funcionalidad de las páginas web, como por ejemplo:

Aplicaciones que se ejecutan en el cliente web, es decir, en el equipo del usuario. El servidor envía el
código (java o javascript) al navegador y este lo ejecuta.
Aplicaciones (en PHP, Perl, Python, etc) que se ejecutan en el servidor y generan un código html que se
envía al navegador, que interpreta y muestra al usuario.

Entre los principales navegadores web están: Firefox, Internet Explorer, Chrome, Amaya, Opera, Dillo,
Epiphany, Midori, etc. Son navegadores para entornos gráficos. Existen otros basados en entornos tipo texto
como: Lynx o Links.

Ejemplo.- Cliente Firefox solicitando la página http://moodle.cipfpbatoi.es

Servidores

El servidor web es una programa que, haciendo uso del protocolo HTTP, atiende las peticiones de los clientes web
para proporcionarles los recursos solicitados.
La ubicación lógica de un servidor web es Internet pero los hay que dan servicio a Intranets o redes locales.

El servidor web, además de suministrar contenido HTML estático (página web que no cambia) también es capaz
de proporcionar páginas dinámicas generadas tras un preprocesamiento de algún programa realizado en PHP,
CGI,, Java, etc. Las páginas dinámicas, a diferencia de las estáticas, muestran contenido variable en función de la
petición que se le haga. Un ejemplo muy típico podría ser los webmail o páginas web de consulta de correo
electrónico.

Veamos gráficamente un esquema donde se resume la arquitectura cliente-servidor del protocolo HTTP.

18 de 31
Unidad 4

Existen muchas implementaciones de servidores web. Las más usadas y más conocidas son: Apache, IIS de
Microsoft, Nginx, Lighttpd, Sun Web Server, Google Web Server, etc.

Actividad

Cuando contratas un servicio de hosting, el proveedor te ofrece una lista de las extensiones
válidas que soporta. En el caso de los proveedores gratuitos esta lista puede ser limitada.
Busca un proveedor de hosting y revisa qué extensiones soporta.
Desde un sistema operativo en modo terminal (ejemplo: ubuntu server) o desde la aplicación
terminal de cualquier sistema Gnu/Linux intenta navegar usando un navegador en modo texto
como Lynx.
Visita la página http://news.netcraft.com/archives/category/web-server-survey/ y busca qué
servidor web es actualmente el más usado en el mundo.

19 de 31
Unidad 4

Seguridad

En este apartado vamos a tratar diferentes aspectos de seguridad relacionados con el servicio web.

El primero de ellos es el uso de HTTPS como elemento, hoy en día, imprescindible para darle confidencialidad a
las comunicaciones. A continuación, vamos a hablar de un de los ataques más comunes que sufren los servidores
web: los ataques DoS.
Para finalizar, vamos a estudiar una guía con consejos prácticos sobre cómo securizar un servidor web concreto:
Apache.

HTTPS

Hyper Text Transfer Protocol Secure (Protocolo seguro de transferencia de hipertexto), más conocido por sus
siglas HTTPS, es un protocolo de aplicación basado en el protocolo HTTP, destinado a la transferencia segura de
datos de Hiper Texto, es decir, es la versión segura de HTTP.

El protocolo HTTPS utiliza un cifrado basado en SSL/TLS para crear un canal cifrado (cuyo nivel de cifrado
depende del servidor remoto y del navegador utilizado por el cliente). Obviamente, este sistema es más apropiado
para el tráfico que transporta información sensible que el protocolo HTTP.

De este modo se consigue que la información no pueda ser usada por un atacante que haya conseguido
interceptar la transferencia de datos de la conexión, ya que lo único que obtendrá será un flujo de datos cifrados
que le resultará imposible de descifrar.
El puerto estándar para este protocolo es el 443.

El funcionamiento del protocolo HTTPS es el siguiente:

20 de 31
Unidad 4

1. El cliente envía el mensaje "hello" que lista las posibilidades criptográficas del cliente (clasificadas por
orden de preferencia del cliente), como la versión de SSL, los grupos de programas de cifrado soportados
por el cliente y los métodos de compresión de datos soportados por el cliente. El mensaje también
contiene un número aleatorio de 28 bytes.
2. El servidor responde con el mensaje "hello" del servidor que contiene el método criptográfico (conjunto
de programas de cifrado) y el método de compresión de datos seleccionados por el servidor, el ID de
sesión y otro número aleatorio.

3. El servidor envía su certificado digital (utiliza certificados digitales X.509 V3 con SSL.)
4. El cliente (navegador web) verifica la validez del certificado digital del servidor y comprueba que los
parámetros del mensaje del servidor son aceptables.

5. El cliente envía el mensaje "client key exchange". Este mensaje contiene el secreto pre-maestro (un
número aleatorio de 46 bytes utilizado en la generación de las claves de cifrado simétrico y las claves de
código de autenticación de mensajes (MAC)) cifrado con la clave pública del servidor.
Nota: No es necesario un proceso adicional para verificar el certificado digital del servidor. Si el servidor no
tiene la clave privada que pertenece al certificado digital, no podrá descifrar el secreto pre-maestro y crear
las claves correctas para el algoritmo de cifrado simétrico y el protocolo de enlace dará error.
6. El cliente utiliza una serie de operaciones criptográficas para convertir el secreto pre-maestro en un
secreto maestro (clave de cifrado simétrica), del que se deriva todo el material de clave necesario para el
cifrado y la autenticación de mensajes.
El servidor hará lo propio con el secreteo pre-maestro que reciba.
A continuación, el cliente envía el mensaje "change cipher spec" para que el servidor conmute al
conjunto de programas de cifrado recién negociado. El siguiente mensaje enviado por el cliente (mensaje
"finished") es el primer mensaje cifrado con este método y estas claves de cifrado.

21 de 31
Unidad 4

7. El servidor responde con mensajes propios "change cipher spec" y "finished".

8. El protocolo de enlace SSL finaliza y los datos de aplicación cifrados se pueden enviar.

Ataques de denegación de servicio: DoS.

De forma general, un ataque de denegación de servicio (DoS de las siglas en inglés Denial of Service o DDoS de
Distributed Denial of Service) es un ataque a un servidor, sistema de servidores o a una red completa que causa
que un servicio o recurso sea inaccesible a los usuarios legítimos. Normalmente provoca la pérdida de la
conectividad de la red por el consumo del ancho de banda de la red de la víctima o sobrecarga de los recursos
computacionales del sistema de la víctima.

En nuestro caso, un DoS sobre un servidor web provocará que nuestro servidor deje de atender peticiones y, por
tanto, quedará inhabilitado. Existen tres estrategias por parte del atacante para conseguirlo:

Ancho de banda: Ataque que consiste en saturar la capacidad de la red del servidor, haciendo que sea
imposible llegar a él.
Recursos: Ataque que consiste en agotar los recursos del sistema de la máquina, impidiendo que ésta
pueda responder a las peticiones legítimas.
Explotación de fallos de software: Categoría de ataque que explota fallos en el software que inhabilitan el
equipo o toman su control.

Podemos ver gráficamente cómo podría ser un ataque de este tipo. Se trata de un ataque real que sufrió el sitio
web de videoLAN (sobre su infraestructura de descargas) y que ha sido representado de la siguiente forma:

DDOS attack on the VideoLAN downloads infrastructure

Cada uno de los pequeños puntos de colores es una petición de acceso al servidor. Las que son del mismo color
pertenecen al mismo host que las envía. A la derecha, vemos al servidor inundado de peticiones, tratando de
servirlas todas (los puntos que rebotan de vuelta al host); los puntos que no recoge la paleta de la derecha y se

22 de 31
Unidad 4

pierden en la pantalla son el número de errores 404 que ven los usuarios que no pueden acceder. La
visualización es realmente gráfica: un DDoS es tal cual, un bombardeo masivo de peticiones que acaban por
tumbar los servidores.

Diferencia entre DoS y DDoS

Los ataques DoS sólo necesitan un equipo y una conexión a Internet para atacar el ancho de banda y recursos de
un objetivo.

Un ataque DDoS usa muchos dispositivos y varias conexiones de Internet que suelen estar distribuidas por todo el
mundo. Por supuesto, ya que el ataque viene desde distintas direcciones es casi imposible de evitar porque,
realmente, no se estará tratando con un solo atacante.
Una forma típica de lograr DDoS es que el atacante explote alguna vulnerabilidad en un sistema y lo convierta en
su “botmaster”. Luego este botmaster identifica otros sistemas vulnerables y los infecta con malware para que se
conviertan en ordenadores zombies. Cuando se controlan suficientes (lo que se llamaría botnet o ejército zombie),
se les mandan instrucciones para que lancen un ataque a un objetivo específico.

Guía para securizar un servidor web Apache

El servidor web Apache es el más utilizado a nivel mundial. Por ello, el organismo INCIBE ha creado una guía
muy interesante con información sobre cómo configurar nuestro servidor para conseguir que sea lo más seguro
posible.

https://www.incibe.es/CERT/guias_estudios/guias/guia_apache

Los temas que se tratan en la guía son:

Cómo modificar la configuración de Apache y las medidas de seguridad que se deben aplicar al instalar el
software.
Las directivas principales para definir los ficheros que servirá Apache sin que se facilite el acceso a ningún
otro archivo del servidor.
Los métodos para tratar de minimizar la información expuesta que facilite ataques sobre el servidor web.
Las características de los distintos métodos de ejecución de código que ofrece Apache y los requisitos de
seguridad que conllevan.
Los métodos Basic y Digest de autenticación, además de cómo construir requisitos de acceso más
sofisticados.
Cómo configurar de manera segura el protocolo HTTPS, que proporciona cifrado de la comunicación y
autenticación del servidor.
Una introducción sobre los ataques DOS y sus mitigaciones. Y cómo configurar Apache en vista del
número de peticiones concurrentes que espera recibir el servidor.
Las opciones de configuración de log y las principales herramientas de monitorización de Apache.

Actividad

En Julio de 2009 se produjeron una serie de Ciberataques tipo DDoS que afectaron a sitios web
de noticias, finanzas y de los gobiernos de Estados Unidos y Corea del Sur. Según las
estimaciones de varias empresas de seguridad, se creó un ejército de alrededor de 50.000
ordenadores zombies ubicados en Corea del Sur. Hubo tres ataques consecutivos: uno el 4 de
julio, día de Independencia en Estados Unidos, donde se vieron afectadas las páginas de la Casa
Blanca y el Pentágono; otro el 7 de julio, el cual afectó únicamente a sitios gubernamentales de
Corea del Sur; y finalmente el 9 de julio, donde se vieron afectados sitios web de ambos países.
Hasta ahora nadie sabe quién o quiénes fueron los atacantes.

23 de 31
Unidad 4

Busca en Internet algún otro ejemplo de ataque DDoS indicando el sitio web que lo sufrió y una
breve descripción del mismo.

24 de 31
Unidad 4

Recursos

25 de 31
Unidad 4

HTTP en la wikipedia

Hypertext Transfer Protocol

De Wikipedia, la enciclopedia libre
(Redirigido desde «Http»)

Hypertext Transfer Protocol o HTTP (en español protocolo

Hypertext Transfer Protocol
de transferencia de hipertexto) es el protocolo usado en (HTTP)
cada transacción de la World Wide Web. HTTP fue
Familia Familia de protocolos de
desarrollado por el World Wide Web Consortium y la
Internet
Internet Engineering Task Force, colaboración que culminó
Función Transferencia de hipertexto
en 1999 con la publicación de una serie de RFC, el más
importante de ellos es el RFC 2616 que especifica la Última 1.2
versión
versión 1.1. HTTP define la sintaxis y la semántica que
utilizan los elementos de software de la arquitectura web Puertos 80/TCP
(clientes, servidores, proxies) para comunicarse. Es un Ubicación en la pila de protocolos
protocolo orientado a transacciones y sigue el esquema Aplicación HTTP
petición-respuesta entre un cliente y un servidor. Al cliente
Transporte TCP
que efectúa la petición (un navegador web o un spider) se lo
conoce como "user agent" (agente del usuario). A la Red IP
información transmitida se la llama recurso y se la identifica Estándares
mediante un localizador uniforme de recursos (URL). El RFC 1945 (HTTP/1.0, 1996)
resultado de la ejecución de un programa, una consulta a RFC 2616 (HTTP/1.1, 1999)
una base de datos, la traducción automática de un RFC 2774 (HTTP/1.2, 2000)
documento, etc. [editar datos en Wikidata]

HTTP es un protocolo sin estado, es decir, que no guarda

ninguna información sobre conexiones anteriores. El desarrollo de aplicaciones web necesita frecuentemente
mantener estado. Para esto se usan las cookies, que es información que un servidor puede almacenar en el
sistema cliente. Esto le permite a las aplicaciones web instituir la noción de "sesión", y también permite rastrear
usuarios ya que las cookies pueden guardarse en el cliente por tiempo indeterminado.

Índice
1 Transacciones HTTP
2 Versiones
3 Ejemplo de un diálogo HTTP
4 Métodos de petición
5 Códigos de respuesta
6 Véase también
7 Referencias
8 Enlaces externos

Transacciones HTTP[editar]

Una transacción HTTP está formada por un encabezado seguido, opcionalmente, por una línea en blanco y algún
dato. El encabezado especificará cosas como la acción requerida del servidor, o el tipo de dato retornado, o el
código de estado.

El uso de campos de encabezados enviados en las transacciones HTTP le dan gran flexibilidad al protocolo.
Estos campos permiten que se envíe información descriptiva en la transacción, permitiendo así la autenticación,
cifrado e identificación de usuario.

26 de 31
Unidad 4

Un encabezado es un bloque de datos que precede a la información propiamente dicha, por lo que muchas veces
se hace referencia a él como metadato —porque tiene datos sobre los datos—.

Si se reciben líneas de encabezado del cliente, el servidor las coloca en las variables de entorno de CGI con el
prefijo HTTP_ seguido del nombre del encabezado. Cualquier carácter guion ( - ) del nombre del encabezado se
convierte a caracteres "_".

El servidor puede excluir cualquier encabezado que ya esté procesado, como Authorization, Content-type y
Content-length. El servidor puede elegir excluir alguno o todos los encabezados, si incluirlos, si se excede algún
límite del entorno de sistema. Ejemplos de esto son las variables HTTP_ACCEPT y HTTP_USER_AGENT.

HTTP_ACCEPT. Los tipos MIME que el cliente aceptará, dados los encabezados HTTP. Otros protocolos
quizás necesiten obtener esta información de otro lugar. Los elementos de esta lista deben estar separados
por una coma, como se dice en la especificación HTTP: tipo, tipo.
HTTP_USER_AGENT. El navegador que utiliza el cliente para realizar la petición. El formato general para
esta variable es: software/versión biblioteca/versión.

El servidor envía al cliente:

Un código de estado que indica si la petición fue correcta o no. Los códigos de error típicos indican que el
archivo solicitado no se encontró, que la petición no se realizó de forma correcta o que se requiere
autenticación para acceder al archivo.
La información propiamente dicha. Como HTTP permite enviar documentos de todo tipo y formato, es ideal
para transmitir multimedia, como gráficos, audio y video. Esta libertad es una de las mayores ventajas de
HTTP.
Información sobre el objeto que se retorna.

Hay que tener en cuenta que la lista no es una lista completa de los campos de encabezado y que todos ellos sólo
tienen sentido en una dirección.

Versiones[editar]

HTTP ha pasado por múltiples versiones del protocolo, muchas de las cuales son compatibles con las anteriores.
El RFC 2145 describe el uso de los números de versión de HTTP. El cliente le dice al servidor al principio de la
petición la versión que usa, y el servidor usa la misma o una anterior en su respuesta.

0.9
Obsoleta. Soporta sólo un comando, GET, y además no especifica el número de versión HTTP. No soporta
cabeceras. Como esta versión no soporta POST, el cliente no puede enviarle mucha información al servidor.
HTTP/1.0 (mayo de 1996)
Esta es la primera revisión del protocolo que especifica su versión en las comunicaciones, y todavía se usa
ampliamente, sobre todo en servidores proxy.
HTTP/1.1 (junio de 1999)[1] [2]

Versión actual; las conexiones persistentes están activadas por defecto y funcionan bien con los proxies.
También permite al cliente enviar múltiples peticiones a la vez por la misma conexión (pipelining) lo que hace
posible eliminar el tiempo de Round-Trip delay por cada petición.

HTTP/1.2
Los primeros borradores de 1995 del documento PEP — an Extension Mechanism for HTTP (el cuál propone
el Protocolo de Extensión de Protocolo, abreviado PEP) los hizo el World Wide Web Consortium y se envió al
Internet Engineering Task Force. El PEP inicialmente estaba destinado a convertirse en un rango distintivo de
HTTP/1.2.[3] En borradores posteriores, sin embargo, se eliminó la referencia a HTTP/1.2. El RFC 2774
(experimental), HTTP Extension Framework, incluye en gran medida a PEP. Se publicó en febrero de 2000.

27 de 31
Unidad 4

Ejemplo de un diálogo HTTP[editar]

Para obtener un recurso con el URL http://www.example.com/index.html

1. Se abre una conexión al host www.example.com, puerto 80 que es el puerto predefinido para HTTP.
2. Se envía un mensaje en el estilo siguiente:

GET /index.html HTTP/1.1 Host: www.example.com User-Agent: nombre-cliente [Línea en blanco

La respuesta del servidor está formada por encabezados seguidos del recurso solicitado, en el caso de una
página web:

HTTP/1.1 200 OK Date: Fri, 31 Dec 2003 23:59:59 GMT Content-Type: text/html Content-Length: 12

Métodos de petición[editar]

HTTP define 8 métodos (algunas veces referido como "verbos") que

indica la acción que desea que se efectúe sobre el recurso
identificado. Lo que este recurso representa, si los datos pre-
existentes o datos que se generan de forma dinámica, depende de la
aplicación del servidor. A menudo, el recurso corresponde a un
archivo o la salida de un ejecutable que residen en el servidor.

HEAD
Pide una respuesta idéntica a la que correspondería a una
petición GET, pero sin el cuerpo de la respuesta. Esto es útil para
Un pedido HTTP usando telnet. El pedido
la recuperación de meta-información escrita en los encabezados (request), cabeceras de respuesta (response
de respuesta, sin tener que transportar todo el contenido. headers) y el cuerpo de la respuesta
(response body) están resaltados.
GET
Pide una representación del recurso especificado. Por seguridad no debería ser usado por aplicaciones que
causen efectos ya que transmite información a través de la URI agregando parámetros a la URL. La petición
puede ser simple, es decir en una línea o compuesta de la manera que muestra el ejemplo.
Ejemplo:
GET /images/logo.png HTTP/1.1 obtiene un recurso llamado logo.png
Ejemplo con parámetros:
/index.php?page=main&lang=es

POST
Envía los datos para que sean procesados por el recurso identificado. Los datos se incluirán en el cuerpo de la
petición. Esto puede resultar en la creación de un nuevo recurso o de las actualizaciones de los recursos
existentes o ambas cosas.

PUT
Sube, carga o realiza un upload de un recurso especificado (archivo), es el camino más eficiente para subir
archivos a un servidor, esto es porque en POST utiliza un mensaje multiparte y el mensaje es decodificado
por el servidor. En contraste, el método PUT te permite escribir un archivo en una conexión socket establecida
con el servidor.
La desventaja del método PUT es que los servidores de hosting compartido no lo tienen habilitado.
Ejemplo:
PUT /path/filename.html HTTP/1.1

28 de 31
Unidad 4

DELETE
Borra el recurso especificado.

TRACE
Este método solicita al servidor que envíe de vuelta en un mensaje de respuesta, en la sección del cuerpo de
entidad, toda la data que reciba del mensaje de solicitud. Se utiliza con fines de comprobación y diagnóstico.

OPTIONS
Devuelve los métodos HTTP que el servidor soporta para un URL específico. Esto puede ser utilizado para
comprobar la funcionalidad de un servidor web mediante petición en lugar de un recurso específico.

CONNECT
Se utiliza para saber si se tiene acceso a un host, no necesariamente la petición llega al servidor, este método
se utiliza principalmente para saber si un proxy nos da acceso a un host bajo condiciones especiales, como
por ejemplo "corrientes" de datos bidireccionales encriptadas (como lo requiere SSL).

Códigos de respuesta[editar]

Artículo principal: Anexo:Códigos de estado HTTP

1xx Mensajes

N° Descripción
100 111 Conexión rechazada

2xx Operación exitosa

N° Descripción
200 OK
201-203 Información no oficial
204 Sin Contenido
205 Contenido para recargar
206 Contenido parcial

3xx Redirección

N° Descripción
301 Mudado permanentemente
302 Encontrado
303 Vea otros
304 No modificado
305 Utilice un proxy
307 Redirección temporal

4xx Error por parte del cliente

N° Descripción
400 Solicitud incorrecta
401 No autorizado
402 Pago requerido
403 Prohibido

29 de 31
Unidad 4

404 No encontrado
409 Conflicto
410 Ya no disponible
412 Falló precondición

5xx Error del servidor

N° Descripción
500 Error interno
501 No implementado
502 Pasarela incorrecta
503 Servicio no disponible
504 Tiempo de espera de la pasarela agotado
505 Versión de HTTP no soportada

Véase también[editar]

Transport Layer Security

HTTPS
HTTP Strict Transport Security
HTTP (P2P)

Referencias[editar]

1. ↑ Enero de 1997. Se publica la primera versión de la especificación HTTP/1.1

2. ↑ Junio de 1999. Publicada la última versión de la especificación HTTP/1.1
3. ↑ [1] PEP: An Extension Mechanism for HTTP. Cita: "For experimental purposes, PEP-compatibility is
equated with HTTP/1.2."

Enlaces externos[editar]

RFC-2616
HTTP - Hypertext Transfer Protocol. W3C
HTTP Made Really Easy. byJames Marshall, 1997
Validación de HTTP Headers Verificación de URL Online
Obtenido de «https://es.wikipedia.org/w/index.php?title=Hypertext_Transfer_Protocol&oldid=85110288»

30 de 31
Unidad 4

RFC 2616 HTTP

Request For Comments del servicio HTTP

Las solicitudes de comentarios (RFC, Requests for Comments) son un conjunto de informes, propuestas de
protocolos y estándares de protocolos utilizados por la comunidad de Internet.

La RFC 2616 contiene información sobre el protocolo que rige al protocolo HTTP.

En el año 2006, el consorcio W3C inició una revisión del RFC 2616 y dicho trabajo finalizó con la publicación de
los RFC 723X., que dejan obsoleto al 2616.
Este trabajo puede verse en el enlace http://www.w3.org/Protocols/

31 de 31