O que é uma transformação por URL?

Uma transformação por URL expressa instruções de processamento de mídia em uma URL de requisição para que um ativo derivado possa ser gerado ou recuperado durante a entrega. Assinaturas e a validação de parâmetros podem restringir as operações permitidas.

Um serviço de transformação por URL lê duas informações da URL de requisição: qual ativo de origem usar e o que fazer com ele. Quando não há um resultado no cache, o serviço busca a origem, executa o processamento, armazena o resultado e o retorna; quando há, retorna o resultado armazenado sem processar novamente. A Cloudflare descreve essa sequência para suas transformações de imagens, e a Cloudinary cria o arquivo derivado na primeira vez que uma URL de transformação é acessada. Portanto, a URL descreve o processamento e é o ponto de partida para a chave de cache, com duas ressalvas: o serviço pode normalizar a URL primeiro e, quando a saída também depende dos cabeçalhos de requisição, como na seleção automática de formato, uma URL pode produzir vários resultados em cache. A sintaxe varia conforme o serviço: Cloudinary e imgproxy colocam as operações em segmentos do caminho, imgix usa parâmetros de consulta, e o Smart CDN da Transloadit identifica um Template salvo no caminho e passa suas variáveis como parâmetros de consulta. A relevância da ordem em que as operações são escritas também varia. A Cloudinary executa cada componente separado por barra sobre o resultado do anterior, enquanto imgproxy e Fastly Image Optimizer aceitam opções em qualquer ordem e as aplicam em uma sequência interna fixa.

O que impede alguém de solicitar milhares de tamanhos? Nada, a menos que você restrinja quais URLs são válidas. A documentação do Thumbor chama isso de adulteração de URL e apresenta um loop que percorre dimensões como exemplo de ataque, e o imgproxy, que mantém a verificação de assinaturas desativada por padrão, recomenda ativá-la em produção pelo mesmo motivo. Os controles habituais são uma assinatura que abrange as opções e a origem (o imgproxy assina todo o caminho após a assinatura, e o Thumbor assina as opções e a URL da imagem) ou uma lista de transformações permitidas (a configuração de transformações estritas da Cloudinary). Um modelo salvo que expõe algumas variáveis limita quais opções quem faz a chamada pode alterar, mas não quantos valores cada uma aceita: um modelo com uma variável de largura sem restrições ainda permite o loop, então combine-o com a assinatura ou com uma lista fixa de valores permitidos. A assinatura depende de uma chave secreta, por isso as URLs assinadas precisam ser emitidas pelo seu servidor, e não montadas no código do navegador. Uma assinatura só bloqueia novas variantes se abranger todas as opções: o imgix observa que um valor de expires não assinado pode ser alterado livremente na string de consulta.
Duas URLs que produzem a mesma saída compartilham uma entrada de cache? Não presuma que sim: isso depende da chave de cache do serviço e de ele normalizar ou não as URLs. A documentação do CloudFront informa que ?color=red&size=large e ?size=large&color=red são buscados e armazenados em cache separadamente quando o cache se baseia em parâmetros da string de consulta, e que diferenças entre maiúsculas e minúsculas recebem o mesmo tratamento. O cache da CDN da Cloudflare trata strings de consulta com ordens diferentes como distintas por padrão e tem uma configuração opcional, Query String Sort, que ordena os parâmetros antes da consulta ao cache. A cobrança segue regras próprias: a Cloudinary contabiliza transformações escritas de maneiras diferentes, como os mesmos parâmetros em outra ordem, como transformações separadas mesmo quando o resultado é idêntico, e a Cloudflare armazena em cache e cobra separadamente cada combinação única de imagem de origem e parâmetros. Gere URLs com uma única função auxiliar que produza parâmetros em uma ordem fixa e com um padrão fixo de maiúsculas e minúsculas, e arredonde as larguras solicitadas para os valores de uma lista curta de tamanhos.
O que acontece com as variantes existentes quando o arquivo de origem é substituído? Elas podem continuar sendo entregues, porque suas URLs não mudaram. A Cloudinary informa que, após um ativo ser sobrescrito, as versões entregues, com ou sem transformações, podem permanecer em cache nos servidores da CDN a menos que sejam invalidadas, e que cópias também podem permanecer em navegadores e proxies fora da rede da Cloudinary. Ela recomenda um componente de versão na URL quando o arquivo mais recente precisa ser entregue imediatamente. Se você também assina URLs, verifique se a invalidação as abrange: a Cloudinary não invalida URLs assinadas por padrão. O imgproxy tem uma opção cachebuster que altera a URL sem mudar o processamento e recomenda usá-la em vez de uma string de consulta porque essa opção pode ser assinada. Antes do lançamento, planeje uma das duas alternativas: uma versão na URL ou no caminho de origem, ou uma etapa explícita de invalidação.

Use transformações por URL quando não for possível prever e gerar antecipadamente todos os tamanhos ou variantes para layouts responsivos. Dimensões sem limites ou parâmetros não assinados podem permitir processamento abusivo, fragmentação do cache e custos inesperados.

O Smart CDN da Transloadit é um serviço de transformação por URL baseado em Templates. Em uma URL tlcdn.com, o nome do host identifica seu Workspace, o caminho identifica um Template salvo e o arquivo de origem, e os parâmetros de consulta preenchem as Assembly Variables que o Template lê, como ${fields.w} para uma largura. Os próprios Steps de processamento ficam no Template, de modo que quem faz a chamada só pode alterar os valores que o Template expõe. O exemplo documentado passa o parâmetro de consulta w diretamente para a largura de redimensionamento, portanto expor uma variável não limita, por si só, quem faz a chamada aos tamanhos usados nas suas páginas; a orientação da Transloadit é definir quais parâmetros podem ser alterados por quem faz a chamada e autorizar requisições com URLs assinadas. A assinatura é um HMAC que abrange o Workspace, o nome do Template, o caminho do arquivo e os parâmetros de consulta ordenados, o que impede que os parâmetros sejam alterados, e deve ser gerada no seu back-end porque usa seu Auth Secret.

A assinatura é descrita como opcional, e as páginas vinculadas não explicam como URLs não assinadas são recusadas. Por isso, confirme esse comportamento no seu próprio Workspace antes de depender de assinaturas para bloquear novas variantes. As páginas também não descrevem uma operação de expurgo do cache nem o que acontece com um resultado em cache quando o arquivo de origem é substituído no mesmo caminho. Armazenar uma substituição em um novo caminho altera a URL; teste o caso em que o caminho permanece igual no seu próprio Workspace antes de depender desse comportamento.

Explore os recursos de entrega da Transloadit

O que é uma transformação por URL?

Como funcionam as transformações por URL

Informações essenciais

Quando as transformações por URL são importantes

Como a Transloadit ajuda com transformações por URL

Fontes

Transforme conhecimento sobre mídia em um pipeline funcional