Qu’est-ce qu’une URL de média ?

Une URL de média identifie une image, une vidéo, un fichier audio, un manifeste ou un rendu généré à un point de terminaison réseau. Son chemin et ses paramètres de requête peuvent sélectionner une ressource source, une transformation ou une politique de diffusion.

Une URL de média est l’adresse par laquelle un client récupère un fichier original, un rendu, un segment ou un manifeste de streaming. Le serveur détermine la signification de chaque partie : généralement, le chemin identifie la ressource et les paramètres de requête contiennent les réglages de transformation ou une signature. L’URL ne détermine pas le format de la réponse. L’en-tête HTTP Content-Type indique le type de média ; l’extension de fichier dans un chemin ne détermine donc pas ce que reçoit un client. D’autres en-têtes de réponse régissent la mise en cache, la diffusion par plages d’octets et l’utilisation interorigines. Un manifeste de streaming ajoute un niveau supplémentaire, car c’est un fichier contenant d’autres URL : en HLS, une URI relative dans une liste de lecture est résolue par rapport à l’URL de la liste de lecture qui la contient. L’URL du manifeste détermine donc où un lecteur cherche les segments.

La chaîne de requête fait-elle partie de la clé de cache ? Cela dépend du CDN et de sa configuration ; vérifiez donc ce point avant d’y placer des paramètres de transformation. HTTP définit une clé de cache comme comprenant au minimum la méthode de requête et l’URI cible. La clé par défaut de Cloudflare inclut l’URL complète avec sa chaîne de requête. Celle d’Amazon CloudFront contient uniquement le nom de domaine de la distribution et le chemin de l’URL. Deux URL qui ne diffèrent que par un paramètre tel que ?w= renvoient donc le même objet en cache tant qu’une politique de cache n’ajoute pas ce paramètre à la clé. L’ajout d’un paramètre qui ne modifie pas la réponse a un coût inverse : CloudFront avertit que cela peut entraîner la mise en cache d’objets en double et réduire le taux de succès du cache.
Une URL de fichier vidéo ou audio nécessite-t-elle un serveur prenant en charge les plages d’octets ? Pour se déplacer dans la lecture sur iOS, oui : la documentation archivée de Safari d’Apple précise que les serveurs hébergeant des fichiers multimédias pour iOS doivent prendre en charge les requêtes par plages d’octets, qu’iOS utilise pour accéder à différentes positions pendant la lecture. MDN décrit plus généralement les requêtes par plages comme utiles aux lecteurs multimédias permettant cet accès à différentes positions. HTTP lui-même rend les requêtes par plages facultatives, et un serveur peut ignorer l’en-tête Range et répondre 200 avec le fichier entier. Un CDN peut ajouter ses propres conditions : CloudFront renvoie l’objet entier au lieu de la plage demandée lorsque l’origine répond avec Transfer-Encoding: chunked. Envoyez une requête par plage à l’URL publique, et pas seulement à l’origine, et vérifiez que vous obtenez une réponse 206 avec un en-tête Content-Range.
Que deviennent les URL des segments lorsque l’URL d’un manifeste HLS est signée ? Une signature dans la chaîne de requête du manifeste ne leur est pas transmise. Les URI relatives des segments sont résolues par rapport à l’URL de la liste de lecture, et la résolution standard des références d’URI conserve la chaîne de requête de la référence relative, et non celle de l’URL de base. Les requêtes de segments arrivent donc sans signature, sauf si la liste de lecture est réécrite pour chaque spectateur ou si l’accès est accordé autrement. La documentation d’Amazon CloudFront recommande des cookies signés plutôt que des URL signées pour donner accès à plusieurs fichiers restreints et cite comme exemple tous les fichiers d’une vidéo HLS.
Les octets accessibles à une URL peuvent-ils changer ? Si c’est le cas, un cache contenant l’ancienne réponse peut continuer à la diffuser tant qu’elle est fraîche. Donnez donc à la réponse une courte durée de fraîcheur ou exigez une revalidation lorsque les mises à jour doivent devenir visibles rapidement. Publier chaque version à une nouvelle URL évite ce problème : la RFC 8246 décrit les URL versionnées comme le modèle permettant une très longue durée de fraîcheur sans avoir à deviner quand une ressource sera mise à jour, et MDN recommande une longue durée pour max-age lorsque les URL incluent un numéro de version ou une empreinte.

Renvoyez des URL de médias stables lorsque les clients intègrent des ressources dans des pages, des lecteurs ou des réponses d’API. Une URL signée limite l’accès. Lorsqu’elle comporte une date d’expiration, les requêtes effectuées après cette date sont refusées ; elle ne convient donc pas aux références durables, et chaque nouvelle signature constitue une nouvelle URL pour tout cache dont la clé inclut la chaîne de requête complète.

Transloadit fournit des URL de médias de deux façons. Chaque fichier de résultat dans un Assembly Status comporte un champ url et un champ ssl_url. Lorsqu’un résultat est exporté avec un Robot de stockage tel que /s3/store, l’Assembly Status renvoie l’URL du fichier dans votre bucket. Cette URL localise l’objet stocké, mais ne rend pas public un objet privé et n’accorde pas d’accès en lecture. Ne la publiez donc que là où les spectateurs sont autorisés à lire l’objet ; sinon, publiez une URL de stockage ou de CDN autorisant l’accès à cet objet. Les URL du stockage temporaire de Transloadit sont supprimées automatiquement, et la documentation précise qu’elles ne sont pas destinées à diffuser du contenu aux utilisateurs finaux. Une URL du Smart CDN a la forme https://[your-workspace].tlcdn.com/[template-name]/[file-path]?[parameters] : le nom du Template et le chemin du fichier sélectionnent le flux de travail et l’original, et les paramètres de requête sont transmis au Template comme réglages de transformation. Elle peut être signée avec une date d’expiration exp et une signature sig, et la durée effective de mise en cache d’une réponse signée est limitée par la durée de validité restante de la signature.

Pour les réponses du Smart CDN, les en-têtes par défaut documentés du Robot /file/serve incluent Accept-Ranges: bytes et un en-tête Content-Type issu du type MIME détecté du fichier.

Explorer les capacités de diffusion de Transloadit

Qu’est-ce qu’une URL de média ?

Fonctionnement des URL de médias

Points clés

Quand les URL de médias sont importantes

Comment Transloadit facilite l’utilisation des URL de médias

Références

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