O que é uma URL de imagem?

Uma URL de imagem é um endereço de rede que identifica um recurso de imagem e pode incluir parâmetros de transformação ou distribuição. Ela pode se referir a um arquivo fixo ou a um serviço que gera uma resposta com base no caminho ou na consulta da requisição.

Uma URL de imagem cumpre duas funções: identifica um recurso e é o principal componente da chave usada por navegadores e CDNs para armazenar a resposta. Um caminho fixo pode corresponder a bytes armazenados. Já um serviço de transformação interpreta a URL como uma receita: o imgproxy, por exemplo, lê as opções de processamento e o endereço de origem nos segmentos do caminho e o formato de saída na extensão, enquanto outros serviços obtêm o tamanho ou o formato dos parâmetros de consulta. O cliente faz uma requisição à URL, o servidor pode escolher entre representações usando cabeçalhos de requisição como Accept, e cada cache armazena o resultado com uma chave formada pela URL e por quaisquer outros elementos que esteja configurado para incluir nela, como os cabeçalhos de requisição que a resposta lista em Vary. Duas URLs que diferem apenas em um detalhe ignorado pelo serviço ainda são armazenadas separadamente por qualquer cache que mantenha esse detalhe na chave.

A extensão do arquivo determina o formato da imagem? Não. Um serviço pode interpretar a extensão como o formato de saída solicitado, como faz o imgproxy, mas é a resposta que determina o formato: o servidor declara o formato em Content-Type e, para um elemento img, o padrão HTML diz que os navegadores também devem examinar os bytes iniciais da imagem para detectar o formato, enquanto o cabeçalho informa o tipo oficial. Uma URL terminada em .jpg pode, portanto, entregar WebP ou AVIF e ainda exibir a imagem. Quando o servidor escolhe esse formato com base no cabeçalho de requisição Accept, uma URL tem várias respostas: o servidor deve enviar Vary: Accept, e cada CDN ou proxy de cache à frente dele precisa levar Accept em conta, ou um cache pode reutilizar um WebP ou AVIF armazenado para um navegador que não o solicitou. A extensão importa para alguns intermediários: a CDN da Cloudflare decide o que armazenar em cache por padrão com base na extensão do arquivo, e não no tipo MIME. Por isso, uma URL de imagem sem uma extensão listada não é armazenada em cache por padrão, a menos que uma regra de cache determine isso.
Duas URLs com os mesmos parâmetros em ordens diferentes são iguais para um cache? Apenas quando o cache normaliza a string de consulta ou a exclui da chave. A RFC 3986 compara URIs como strings, e suas regras de normalização não reordenam os parâmetros de consulta. A documentação do Amazon CloudFront informa que, quando o cache se baseia em parâmetros da string de consulta, ?color=red&size=large e ?size=large&color=red são armazenados em cache como dois objetos, e a distinção entre maiúsculas e minúsculas nos nomes e valores dos parâmetros também conta. A Cloudflare inclui a string de consulta completa na chave de cache padrão e lista as opções Sort query string e Ignore query string. Gerar parâmetros sempre na mesma ordem e com o mesmo uso de maiúsculas e minúsculas evita entradas de cache e transformações duplicadas. O inverso também importa: um parâmetro que altera a imagem precisa fazer parte da chave de cache, porque um cache configurado para ignorar a string de consulta atribui a mesma chave a URLs que diferem apenas nos parâmetros.
Qualquer pessoa pode alterar os parâmetros de uma URL de transformação? Sim, a menos que o serviço recuse requisições sem uma assinatura válida ou restrinja de outra forma o que aceita. Gerar URLs assinadas não basta se o serviço continuar atendendo às não assinadas: o imgproxy deixa a verificação de assinatura desativada por padrão e recomenda ativá-la em produção, para que um invasor não consiga realizar um ataque de negação de serviço solicitando muitos redimensionamentos diferentes; sua assinatura é um HMAC calculado sobre o caminho da URL. Uma assinatura abrange apenas a URL: o imgproxy observa que cabeçalhos de requisição não podem ser assinados, o que importa quando o formato de saída ou a largura é obtido de um cabeçalho.
Por que uma página pode exibir uma imagem de outra origem, mas não ler seus pixels? Uma página normalmente pode exibir uma imagem de outra origem, mas desenhá-la em um canvas sem permissão de CORS contamina o canvas. Depois disso, getImageData(), toBlob() e toDataURL() lançam um SecurityError; isso impede que uma página use imagens para extrair dados privados de outros sites. Para ler os pixels, o servidor que hospeda a imagem precisa enviar um cabeçalho Access-Control-Allow-Origin que permita o acesso pela página, e o elemento img precisa do atributo crossorigin (definido como crossOrigin quando um script cria a imagem). Com crossorigin, o navegador envia um cabeçalho de requisição Origin, que não está presente em uma requisição comum de img para outra origem. A Cloudflare inclui o cabeçalho Origin da requisição em sua chave de cache padrão, então requisições para uma mesma URL que diferem nesse cabeçalho são armazenadas separadamente no cache da Cloudflare.

A forma de uma URL de imagem passa a ser importante quando a imagem é transformada sob demanda ou entregue por uma CDN, pois a URL passa a determinar tanto quais bytes são produzidos quanto qual cópia em cache é reutilizada. Antes de publicar as URLs, defina a ordem dos parâmetros e o uso de maiúsculas e minúsculas, se o formato de saída será especificado na URL ou negociado a partir do cabeçalho Accept (a negociação só é segura quando todos os caches à frente do serviço mantêm os formatos separados) e se a URL será assinada; páginas e outros sistemas que armazenaram uma URL continuam solicitando exatamente aquela forma.

Uma URL de imagem do Smart CDN da Transloadit é uma URL de transformação desse tipo. O nome do Workspace é o subdomínio de tlcdn.com, o caminho contém o nome do Template e o caminho do arquivo de origem, e parâmetros de consulta como w=730 chegam ao Template como Assembly Variables, como ${fields.w}. Assim, o Template determina quais parâmetros têm algum efeito. A URL pode ser assinada com um prazo de expiração (exp) e uma assinatura (sig); a assinatura precisa ser gerada no seu back-end porque usa o Auth Secret. Se uma URL assinada ou seus parâmetros forem alterados depois disso, a assinatura deixa de corresponder. Isso só impede que terceiros alterem a URL ou seus parâmetros quando requisições não assinadas são recusadas, e as páginas vinculadas não descrevem como uma requisição não assinada ao mesmo Template é tratada. Por isso, teste esse comportamento no seu próprio Workspace antes de confiar na assinatura.

O procedimento de assinatura ordena os parâmetros de consulta antes de calcular a assinatura. As páginas vinculadas não informam se duas URLs cujos parâmetros diferem apenas na ordem compartilham um único resultado em cache, então gere os parâmetros em uma ordem fixa.

Explore os recursos de entrega da Transloadit

O que é uma URL de imagem?

Como funcionam as URLs de imagens

Informações essenciais

Quando as URLs de imagens são importantes

Como a Transloadit ajuda com URLs de imagens

Fontes

Transforme conhecimento sobre mídia em um pipeline funcional