¿Qué es una URL de imagen?

Una URL de imagen es una dirección de red que identifica un recurso de imagen y puede incluir parámetros de transformación o entrega. Puede hacer referencia a un archivo fijo o a un servicio que genera una respuesta a partir de la ruta o la consulta solicitada.

Una URL de imagen cumple dos funciones: identifica un recurso y es la parte principal de la clave con la que los navegadores y las CDN almacenan la respuesta. Una ruta fija puede corresponder a bytes almacenados. En cambio, un servicio de transformación interpreta la URL como una receta: imgproxy, por ejemplo, lee las opciones de procesamiento y la dirección de origen de los segmentos de la ruta, y el formato de salida de la extensión, mientras que otros servicios obtienen un tamaño o formato de los parámetros de consulta. El cliente solicita la URL, el servidor puede elegir entre representaciones mediante encabezados de solicitud como Accept, y cada caché almacena el resultado bajo la URL junto con cualquier otro elemento que esté configurada para incluir en su clave, como los encabezados de solicitud que la respuesta nombra en Vary. Dos URL que solo difieren en un detalle que el servicio ignora siguen almacenándose por separado en cualquier caché que conserve ese detalle en su clave.

¿La extensión del archivo determina el formato de la imagen? No. Un servicio puede interpretar la extensión como el formato de salida solicitado, como hace imgproxy, pero lo que determina el formato es la respuesta: el servidor lo declara en Content-Type, y para un elemento img el estándar HTML indica que los navegadores también deberían inspeccionar los primeros bytes de la imagen, mientras que el encabezado proporciona el tipo oficial. Por tanto, una URL que termina en .jpg puede entregar WebP o AVIF y la imagen puede mostrarse igualmente. Cuando el servidor elige ese formato a partir del encabezado de solicitud Accept, una URL tiene varias respuestas: el servidor debería enviar Vary: Accept, y toda CDN o proxy de caché que tenga delante debe tener en cuenta Accept; de lo contrario, una caché puede reutilizar un WebP o AVIF almacenado para un navegador que no lo solicitó. La extensión sí importa para algunos intermediarios: la CDN de Cloudflare decide qué almacenar en caché de forma predeterminada a partir de la extensión del archivo y no del tipo MIME, por lo que una URL de imagen sin una extensión incluida en su lista no se almacena en caché de forma predeterminada, salvo que una regla de caché lo indique.
¿Dos URL con los mismos parámetros en distinto orden son iguales para una caché? Solo cuando la caché normaliza la cadena de consulta o la excluye de su clave. El RFC 3986 compara las URI como cadenas, y sus reglas de normalización no reordenan los parámetros de consulta. Amazon CloudFront documenta que, cuando almacena en caché según los parámetros de la cadena de consulta, ?color=red&size=large y ?size=large&color=red se almacenan como dos objetos, y que también se distingue entre mayúsculas y minúsculas en los nombres y valores de los parámetros. Cloudflare incluye toda la cadena de consulta en su clave de caché predeterminada y enumera las opciones de ordenar la cadena de consulta e ignorarla. Generar los parámetros siempre en el mismo orden y con el mismo uso de mayúsculas y minúsculas evita entradas de caché duplicadas y transformaciones duplicadas. Lo contrario también importa: un parámetro que cambie la imagen debe formar parte de la clave de caché, porque una caché configurada para ignorar la cadena de consulta asigna la misma clave a las URL que solo difieren en sus parámetros.
¿Cualquiera puede cambiar los parámetros de una URL de transformación? Sí, a menos que el servicio rechace las solicitudes que carezcan de una firma válida o restrinja de otro modo lo que acepta. Generar URL firmadas no basta si el servicio sigue atendiendo las que no están firmadas: imgproxy deja desactivada la verificación de firmas de forma predeterminada y recomienda activarla en producción para que un atacante no pueda realizar un ataque de denegación de servicio solicitando muchos cambios de tamaño distintos; su firma es un HMAC sobre la ruta de la URL. Una firma solo cubre la URL: imgproxy señala que los encabezados de solicitud no pueden firmarse, lo que importa cuando el formato o el ancho de salida se obtiene de un encabezado.
¿Por qué una página puede mostrar una imagen de otro origen, pero no leer sus píxeles? Una página normalmente puede mostrar una imagen de otro origen, pero dibujarla en un canvas sin autorización CORS contamina el canvas, tras lo cual getImageData(), toBlob() y toDataURL() lanzan un SecurityError; esto impide que una página use imágenes para extraer datos privados de otros sitios. Para leer los píxeles, el servidor que aloja la imagen debe enviar un encabezado Access-Control-Allow-Origin que autorice a la página, y el elemento img necesita el atributo crossorigin (establecido mediante crossOrigin cuando un script crea la imagen). Con crossorigin, el navegador envía un encabezado de solicitud Origin, que una solicitud img normal a otro origen no incluye. Cloudflare incluye el encabezado Origin de la solicitud en su clave de caché predeterminada, por lo que allí se almacenan en caché por separado las solicitudes de una misma URL que difieren en ese encabezado.

La forma de una URL de imagen empieza a importar cuando la imagen se transforma al solicitarla o se sirve mediante una CDN, porque entonces la URL determina tanto los bytes que se producen como la copia en caché que se reutiliza. Antes de publicar las URL, define el orden de los parámetros y su uso de mayúsculas y minúsculas, si el formato de salida se indica en la URL o se negocia a partir del encabezado Accept (la negociación solo es segura cuando todas las cachés que están delante del servicio mantienen separados los formatos), y si la URL se firma; las páginas y otros sistemas que hayan almacenado una URL siguen solicitando esa forma exacta.

Una URL de imagen de Smart CDN de Transloadit es una URL de transformación de este tipo. El nombre del Workspace es el subdominio de tlcdn.com, la ruta contiene el nombre del Template y la ruta del archivo de origen, y los parámetros de consulta como w=730 llegan al Template como Assembly Variables, por ejemplo ${fields.w}, de modo que el Template decide qué parámetros tienen algún efecto. La URL puede firmarse con una fecha y hora de vencimiento (exp) y una firma (sig); la firma debe generarse en tu backend porque usa el Auth Secret. Si una URL firmada o sus parámetros se modifican después, la firma deja de coincidir. Esto impide que terceros alteren la URL o sus parámetros solo cuando se rechazan las solicitudes sin firma, y las páginas enlazadas no describen cómo se trata una solicitud sin firma al mismo Template, así que pruébalo en tu propio Workspace antes de depender de las firmas.

El procedimiento de firma ordena los parámetros de consulta antes de calcular la firma. Las páginas enlazadas no indican si dos URL cuyos parámetros solo difieren en el orden comparten un mismo resultado en caché, así que genera los parámetros en un orden fijo.

Explora las capacidades de entrega de Transloadit

¿Qué es una URL de imagen?

Cómo funcionan las URL de imágenes

Datos clave

Cuándo importan las URL de imágenes

Cómo ayuda Transloadit con las URL de imágenes

Fuentes

Convierte tus conocimientos sobre multimedia en un pipeline funcional