Resumen

  • La RFC 2397 definió data: para pequeños datos «inmediatos»: tipo de medio opcional, marca ;base64 opcional, una coma y los datos.
  • Al viajar los bytes dentro de la URL, el punto de control pasó del camino de recuperación remota al consumidor, su política de medios y su límite de memoria.

Una URL corriente contiene la promesa de un viaje. El cliente lee un lugar, contacta con algo externo y recibe una representación. La RFC 2397 propuso una ruta más corta. En data:[<mediatype>][;base64],<data>, la cadena que suele indicar adónde ir también transporta aquello que debe leerse.

El documento llamó a esto «direccionamiento inmediato». No hay un servidor diminuto detrás de la coma. Para ese elemento incorporado no existe una segunda ubicación: el consumidor separa declaración y carga, reconstruye los octetos y los interpreta según el tipo de medio. Puntero y mercancía quedan serializados juntos.

Las reglas de omisión son exactas. Si falta el tipo, se usa text/plain;charset=US-ASCII; puede omitirse text/plain y conservarse un charset. La marca ;base64, sin signo igual, selecciona base64 y por eso no es un parámetro normal de Content-Type. Sin ella, los caracteres seguros representan directamente octetos y los demás usan %xx. Base64 no cifra, autentica ni autoriza.

Tampoco existe una forma relativa. Una referencia relativa toma su base del contexto; data: ya entrega tipo y contenido. Así se distingue de la historia de las URL relativas: una hereda una dirección, la otra lleva sus propios bytes.

La RFC insiste en que los valores sean pequeños. Cita los límites SGML de HTML 2.0: 1.024 caracteres para un literal de atributo, 2.100 para el conjunto de valores de un elemento y 2.100 para el elemento completo. Incluso el GIF del ejemplo aparece cerca del límite práctico. No son topes universales de data:; muestran que la gramática, el contenedor y la memoria pueden admitir longitudes distintas.

La sección de seguridad ubica el mando. Un proxy cortafuegos puede impedir que se recupere desde fuera un tipo prohibido. Le resulta más difícil examinar por la misma vía un contenido ya encerrado en una URL. Por eso la aplicación no debería interpretar un tipo que su configuración prohíbe. La puerta efectiva está donde los octetos se convierten en comportamiento.

La especificación también reconocía que se desconocía el efecto de valores muy largos y que ciertos programas podían actuar de manera irrazonable cuando la entrada superaba el búfer asignado. Son dos controles diferentes: ¿se permite ese tipo?, ¿puede procesarse ese tamaño con seguridad? Evitar una recuperación externa no resuelve ninguno.

La idea venía de agosto de 1995 y había aparecido en VRML, propuestas de datos incrustados en HTML, productos comerciales y parámetros de objetos Java y ActiveX. Durante el diseño se permitió omitir el tipo, se compactó el indicador base64 y se eliminó quoted-printable porque %xx ya cumplía la función.

Los errata posteriores deben leerse por estado. Dos correcciones Verified sustituyen el imposible %fg y cambian el urlchar inexistente de RFC 2396 por uric. Las dudas sobre parámetros entrecomillados y delimitadores siguen Reported o Held for Document Update; no son texto aprobado. La propuesta de cambiar todo «URL» por «URI» fue Rejected porque la terminología original era correcta en su momento.

La enseñanza de RFC 2397 es de control. Reducir intermediarios no elimina autoridad: la concentra en el software que analiza, decodifica, interpreta y permite. Cuanto más corta es la ruta, menos ambigua puede ser la frontera local.

Fuentes