Qu’est-ce qu’une transformation par URL ?

Une transformation par URL exprime des instructions de traitement multimédia dans l’URL d’une requête afin qu’une ressource dérivée puisse être générée ou récupérée lors de la diffusion. Les signatures et la validation des paramètres peuvent restreindre les opérations autorisées.

Un service de transformation par URL lit deux informations dans l’URL de la requête : quelle ressource source utiliser et quel traitement lui appliquer. Si le résultat est absent du cache, il récupère la source, exécute le traitement, stocke le résultat et le renvoie ; si le résultat est présent, il renvoie le résultat stocké sans refaire le traitement. Cloudflare décrit cette séquence pour ses transformations d’images, et Cloudinary crée le fichier dérivé lors du premier accès à une URL de transformation. L’URL décrit donc le travail à effectuer et sert de point de départ à la clé de cache, avec deux réserves : un service peut d’abord normaliser l’URL, et lorsque la sortie dépend aussi des en-têtes de requête, comme avec la sélection automatique du format, une même URL peut produire plusieurs résultats en cache. La syntaxe varie selon le service : Cloudinary et imgproxy placent les opérations dans les segments du chemin, imgix utilise des paramètres de requête, et le Smart CDN de Transloadit désigne un Template enregistré dans le chemin et transmet ses variables comme paramètres de requête. L’importance de l’ordre d’écriture des opérations varie également. Cloudinary exécute chaque composant séparé par une barre oblique sur le résultat du précédent, tandis qu’imgproxy et Fastly Image Optimizer acceptent les options dans n’importe quel ordre et les appliquent selon une séquence interne fixe.

Qu’est-ce qui empêche quelqu’un de demander des milliers de tailles ? Rien, sauf si vous restreignez les URL valides. La documentation de Thumbor appelle cela la manipulation d’URL et présente comme attaque une boucle sur les dimensions. Pour la même raison, imgproxy, qui désactive par défaut la vérification des signatures, recommande de l’activer en production. Les contrôles habituels sont une signature couvrant les options et la source (imgproxy signe tout le chemin après la signature, Thumbor signe les options et l’URL de l’image) ou une liste de transformations autorisées (le réglage de transformations strictes de Cloudinary). Un modèle enregistré qui expose quelques variables limite les options qu’un appelant peut modifier, pas le nombre de valeurs que chacune accepte : un modèle avec une variable de largeur libre permet toujours la boucle. Combinez-le donc avec la signature ou une liste fixe de valeurs autorisées. La signature repose sur une clé secrète ; les URL signées doivent donc être émises par votre serveur, pas assemblées dans le code du navigateur. Une signature ne bloque les nouvelles variantes que si elle couvre chaque option : imgix précise qu’une valeur expires non signée peut être modifiée librement dans la chaîne de requête.
Deux URL qui produisent le même résultat partagent-elles une entrée de cache ? Ne le supposez pas : cela dépend de la clé de cache du service et de sa normalisation éventuelle des URL. CloudFront précise que ?color=red&size=large et ?size=large&color=red sont récupérés et mis en cache séparément lorsque la mise en cache repose sur les paramètres de requête, et que les différences de casse sont traitées de la même manière. Par défaut, le cache CDN de Cloudflare distingue les chaînes de requête dont les paramètres sont ordonnés différemment et propose un réglage facultatif Query String Sort qui les trie avant la recherche dans le cache. La facturation suit ses propres règles : Cloudinary compte les transformations écrites différemment, par exemple avec les mêmes paramètres dans un ordre différent, comme des transformations distinctes même si le résultat est identique, et Cloudflare met en cache et facture séparément chaque combinaison unique d’image source et de paramètres. Générez les URL à partir d’une seule fonction utilitaire qui produit les paramètres dans un ordre et une casse fixes, et arrondissez les largeurs demandées aux valeurs d’une courte liste de tailles.
Que deviennent les variantes existantes lorsque le fichier source est remplacé ? Elles peuvent continuer à être diffusées, car leurs URL n’ont pas changé. Cloudinary indique qu’après l’écrasement d’une ressource, les versions diffusées, avec ou sans transformations, peuvent rester en cache sur les serveurs CDN à moins d’être invalidées, et que des copies peuvent également subsister dans les navigateurs et les serveurs mandataires extérieurs à son réseau. Cloudinary recommande d’inclure un composant de version dans l’URL lorsque le fichier le plus récent doit être diffusé immédiatement. Si vous signez également les URL, vérifiez que l’invalidation les couvre : Cloudinary n’invalide pas les URL signées par défaut. imgproxy propose une option cachebuster qui modifie l’URL sans modifier le traitement et la recommande plutôt qu’une chaîne de requête, car elle peut être signée. Prévoyez l’une de ces deux solutions avant le lancement : une version dans l’URL ou le chemin source, ou une étape d’invalidation explicite.

Utilisez les transformations par URL lorsque les tailles adaptatives ou les variantes ne peuvent pas toutes être prévues et générées à l’avance. Des dimensions sans limites ou des paramètres non signés peuvent permettre des traitements abusifs, fragmenter le cache et entraîner des coûts imprévus.

Le Smart CDN de Transloadit est un service de transformation par URL fondé sur les Templates. Dans une URL tlcdn.com, le nom d’hôte désigne votre Workspace, le chemin désigne un Template enregistré et le fichier source, et les paramètres de requête renseignent les Assembly Variables que lit le Template, par exemple ${fields.w} pour une largeur. Les étapes de traitement elles-mêmes sont définies dans le Template, de sorte que l’appelant ne peut modifier que les valeurs exposées par celui-ci. L’exemple documenté transmet directement le paramètre de requête w à la largeur de redimensionnement ; exposer une variable ne suffit donc pas à limiter les appelants aux tailles utilisées par vos pages. Transloadit recommande de définir les paramètres que les appelants peuvent faire varier et d’autoriser les requêtes au moyen d’URL signées. La signature est un HMAC qui couvre le Workspace, le nom du Template, le chemin du fichier et les paramètres de requête triés, ce qui empêche leur altération. Elle doit être générée sur votre serveur, car elle utilise votre Auth Secret.

La signature est présentée comme facultative, et les pages liées n’expliquent pas comment les URL non signées sont refusées. Vérifiez donc ce comportement sur votre propre Workspace avant de compter sur les signatures pour bloquer de nouvelles variantes. Ces pages ne décrivent pas non plus d’opération de purge ni ce que devient un résultat en cache lorsque le fichier source est remplacé au même chemin. Stocker un fichier de remplacement sous un nouveau chemin modifie l’URL ; testez le cas où le chemin reste inchangé sur votre propre Workspace avant de vous y fier.

Explorer les capacités de diffusion de Transloadit

Qu’est-ce qu’une transformation par URL ?

Comment fonctionnent les transformations par URL

Points clés

Quand les transformations par URL sont utiles

Comment Transloadit facilite les transformations par URL

Références

Transformer vos connaissances sur les médias en une chaîne de traitement opérationnelle