El protocolo HTTP: Es la base de las comunicaciones en Internet. Fue desarrollado por la IETF y el W3C. La RFC más importante es la RFC 2616, que define el protocolo 1.1, el más usado actualmente.

• Capa de aplicación. Normalmente la capa de transporte es TCP, pero en algunas aplicaciones es UDP.
• Es un protocolo de petición-respuesta dentro del modelo cliente-servidor. Un agente de usuario (navegador, web crawler) hace de cliente, mientras que una aplicación que se ejecuta en un ordenador en el que hay una página web hace de servidor.
• El servidor almacena y provee recursos, como ficheros HTML, o hace otras funciones para el cliente.
• Las respuestas del servidor contienen un código de salida, y además pueden contener datos solicitados por el cliente.
• El protocolo incluye elementos para hacer las comunicaciones posibles y eficientes.
• Web caché para mejorar la velocidad de respuesta.
• HTTP Proxy’s para clientes en redes privadas.
• Los recursos HTTP están identificados por URI’s o URL’s.

Evolución del Protocolo

• La versión HTTP/1.0 fue revisada con la HTTP/1.1.
• La versión 1.0 usa una conexión TCP diferente para cada petición, la 1.1 permite reusar una conexión varias veces.
• La comunicación presenta menor latencia en la versión 1.1.

Protocolo sin estado

HTTP es un protocolo sin estado: el servidor trata cada petición como una transacción independiente sin relación con peticiones previas.

• Un protocolo sin estado no requiere que el servidor guarde información de sesión o status a través de múltiples peticiones.
• Alternativas: las cookies HTTP, sesiones del lado del servidor, variables ocultas, codificación en la URL.
• Por ejemplo, FTP es un protocolo CON estado.

Métodos de petición

HTTP define nueve métodos (o verbos) para indicar la acción que se quiere efectuar sobre un recurso.

• GET: Método básico para solicitar un recurso. No debería tener más efecto que la petición/entrega de un recurso.
• POST: Envía datos, que serán procesados por el recurso (un formulario). Puede crear o modificar un recurso.
• PUT: Sube un recurso al servidor, de manera más eficiente que POST. Su uso no suele estar habilitado.
• HEAD: Pide una respuesta como la que daría un GET, pero sin el cuerpo de la respuesta. Es útil para ver la metainformación contenida en las cabeceras de las respuestas sin tener que descargar todo el contenido.
• OPTIONS: Devuelve los métodos que soporta un servidor para un recurso determinado.
• DELETE: Borra el recurso especificado.
• TRACE: Devuelve un eco de la petición, para que el cliente pueda ver si ha sufrido cambios (servidores intermedios).
• CONNECT: Convierte la conexión de la petición a un túnel TCP/IP transparente, normalmente para facilitar comunicación HTTPS.
• PATCH: Se usa para actualizar parcialmente algún recurso.

Métodos idempotentes y aplicaciones web

Un método es idempotente si realizar una petición es equivalente a realizar muchas.

• Los métodos DELETE y PUT se definen como idempotentes.
• Los métodos seguros, GET, HEAD, OPTIONS y TRACE, también deberían serlo.
• Por el contrario, el método POST puede no ser idempotente. Por ejemplo, en un formulario para enviar correos, darle varias veces a enviar puede hacer que se envíe el correo varias veces.

Métodos seguros

Algunos de los métodos anteriores se denominan seguros.

• Quiere decir que sirven para pedir información y no causan cambios en el servidor.
• En otras palabras, no deberían tener efectos secundarios más allá de los que no causan ningún problema: logs, contadores de visitas, etc.
• HEAD, GET, OPTIONS y TRACE.
• Los métodos PUT, DELETE y POST, al contrario, pueden modificar recursos o implicar acciones como transacciones financieras o el envío de un correo.
• Para algunos expertos, el método TRACE es potencialmente inseguro.

Ejemplo de comunicación

• Etag se usa para comparar con la versión de la caché, si la hay.
• Content-Type especifica el tipo de contenido (Internet media type), y Content-Length su longitud en bytes.
• Accept-Ranges: bytes. Indica que el servidor puede entregar solo parte del contenido, puede ser útil para ahorrar transmisiones.
• Connection: close. Si se envía, el servidor cerrará la conexión TCP inmediatamente.

Cabeceras

Algunos campos de las cabeceras en las peticiones:

• Referer
• Cookie
• Accept-Language
• User-Agent

Y en las respuestas:

• Etag
• Set-Cookie

Cookies

Un servidor puede enviar una cookie HTTP al cliente, mediante la cabecera correspondiente.

• Esta cookie permite guardar información de la sesión, o entre diferentes sesiones.
• Por lo tanto, sirven para sortear el problema de que el HTTP sea un protocolo sin estado.
• Problemas de seguridad asociados.

Peticiones

Un mensaje de petición consiste en:

• Línea de petición, como GET /images/logo.png HTTP/1.1, que solicita un recurso llamado /images/logo.png al servidor.
• Cabeceras, como Accept-Language: en.
• Una línea vacía.
• Un cuerpo de mensaje opcional.

HTTP seguro

Hay tres métodos para asegurar las comunicaciones por HTTP:

• HTTP Secure
• Secure Hypertext Transfer Protocol
• HTTP/1.1 Upgrade header

HTTP Secure (HTTPS)

HTTPS indica al navegador que debe usar una capa adicional de encriptación SSL/TLS.

• SSL es especialmente adecuado para el HTTP porque permite cierta protección aunque solo una de las partes esté autentificada.
• En internet, normalmente solo el servidor lo está. El cliente examina el certificado del servidor.
• La idea es crear un canal seguro sobre uno inseguro. Permite una seguridad razonable en las comunicaciones si se usan cifrados adecuados y el certificado del servidor es de confianza y verificable.
• Los navegadores tienen una lista de entidades de certificación preinstalada.
• Los creadores del navegador confían en estas entidades como proveedoras de certificados válidos.

Un usuario debería confiar en una conexión HTTP con un servidor si:

• Confía en que su navegador implementa correctamente HTTPS y en sus entidades preinstaladas.
• El sitio web posee un certificado válido, es decir, firmado por una autoridad de confianza.
• El certificado identifica correctamente al sitio web.
• O todos los saltos (hops) en internet son de confianza, o el usuario confía en la seguridad de la capa de encriptación del protocolo.

Código de Estado

La respuesta del servidor incluye un código de estado además del contenido que se le haya podido solicitar. El código lleva asociado un mensaje explicativo.