O que é uma URL de mídia?
Uma URL de mídia identifica uma imagem, um vídeo, um arquivo de áudio, um manifesto ou uma representação gerada em um endpoint de rede. Seu caminho e seus parâmetros de consulta podem selecionar um recurso de origem, uma transformação ou uma política de entrega.
Como funcionam as URLs de mídia
Uma URL de mídia é o endereço pelo qual um cliente obtém um arquivo original, uma representação, um segmento ou um manifesto de streaming. O servidor decide o significado de cada parte: normalmente, o caminho identifica o recurso e os parâmetros de consulta contêm configurações de transformação ou uma assinatura. A URL não determina o formato da resposta. O cabeçalho HTTP Content-Type informa o tipo de mídia, portanto a extensão do arquivo em um caminho não determina o que um cliente recebe. Outros cabeçalhos de resposta controlam o armazenamento em cache, a entrega por intervalos de bytes e o uso entre origens. Um manifesto de streaming acrescenta mais uma camada, pois é um arquivo que contém outras URLs: no HLS, um URI relativo dentro de uma playlist é resolvido em relação à URL da playlist que o contém, de modo que a URL do manifesto determina onde um reprodutor procura os segmentos.
Informações essenciais
- A string de consulta faz parte da chave de cache? Isso depende da CDN e de sua configuração, então verifique antes de colocar parâmetros de transformação nela. O HTTP define uma chave de cache como, no mínimo, o método da solicitação e o URI de destino. A chave padrão da Cloudflare inclui a URL completa com sua string de consulta. A chave padrão do Amazon CloudFront contém apenas o nome de domínio da distribuição e o caminho da URL, de modo que duas URLs que diferem apenas em um parâmetro como
?w=retornam o mesmo objeto em cache até que uma política de cache adicione esse parâmetro à chave. Adicionar um parâmetro que não altera a resposta tem o custo oposto: o CloudFront alerta que isso pode armazenar objetos duplicados em cache e reduzir a taxa de acertos do cache. - Uma URL de arquivo de vídeo ou áudio precisa de um servidor que ofereça suporte a intervalos de bytes? Para navegar pela linha do tempo no iOS, sim: a orientação arquivada da Apple sobre o Safari afirma que servidores que hospedam arquivos de mídia para iOS devem oferecer suporte a solicitações de intervalos de bytes, que o iOS usa para acesso aleatório durante a reprodução. A MDN descreve as solicitações de intervalo de forma mais geral como úteis para reprodutores de mídia que oferecem suporte a acesso aleatório. O próprio HTTP torna as solicitações de intervalo opcionais, e um servidor pode ignorar o cabeçalho
Rangee responder com 200 e o arquivo inteiro. Uma CDN pode acrescentar suas próprias condições: o CloudFront retorna o objeto inteiro em vez do intervalo solicitado quando a origem responde comTransfer-Encoding: chunked. Envie uma solicitação de intervalo à URL pública, não apenas à origem, e espere uma resposta 206 com um cabeçalhoContent-Range. - O que acontece com as URLs dos segmentos quando a URL de um manifesto HLS é assinada? Uma assinatura na string de consulta do manifesto não é propagada para elas. Os URIs relativos dos segmentos são resolvidos em relação à URL da playlist, e a resolução padrão de referências de URI mantém a consulta da referência relativa, não a da URL base, de modo que as solicitações de segmentos chegam sem a assinatura, a menos que a playlist seja reescrita para cada espectador ou o acesso seja concedido de outra forma. A documentação do Amazon CloudFront recomenda cookies assinados em vez de URLs assinadas para conceder acesso a vários arquivos restritos e cita todos os arquivos de um vídeo HLS como exemplo.
- Os bytes associados a uma URL podem mudar? Se puderem, um cache que armazena a resposta anterior pode continuar a fornecê-la enquanto ela estiver dentro do prazo de validade, então defina um prazo de validade curto para a resposta ou exija revalidação quando as atualizações precisarem ficar visíveis rapidamente. Publicar cada versão em uma nova URL evita o problema: a RFC 8246 descreve URLs versionadas como o padrão que permite um prazo de validade muito longo sem precisar adivinhar quando um recurso será atualizado, e a MDN recomenda um
max-agelongo para URLs que incluem um número de versão ou hash.
Quando as URLs de mídia são importantes
Retorne URLs de mídia estáveis quando os clientes incorporarem recursos em páginas, players ou respostas de API. Uma URL assinada limita o acesso. Quando ela contém um prazo de expiração, as solicitações feitas após esse prazo são recusadas, portanto ela não é adequada para referências de longa duração, e cada nova assinatura representa uma nova URL para qualquer cache cuja chave inclua a string de consulta completa.
Como a Transloadit ajuda com URLs de mídia
A Transloadit fornece URLs de mídia de duas formas. Cada arquivo de resultado em um Assembly Status contém um url e um ssl_url. Quando um resultado é exportado com um Robot de armazenamento como o /s3/store, o Assembly Status retorna a URL do arquivo no seu bucket. Essa URL localiza o objeto armazenado, mas não torna público um objeto privado nem concede acesso de leitura. Portanto, publique essa URL apenas onde os usuários tenham permissão para ler o objeto; caso contrário, publique uma URL de armazenamento ou CDN que autorize o acesso a ele. As URLs no armazenamento temporário da Transloadit são removidas automaticamente, e a documentação informa que elas não se destinam a servir conteúdo aos usuários finais. Uma URL do Smart CDN tem o formato https://[your-workspace].tlcdn.com/[template-name]/[file-path]?[parameters]: o nome do Template e o caminho do arquivo selecionam o fluxo de trabalho e o original, e os parâmetros de consulta chegam ao Template como configurações de transformação. Ela pode ser assinada com um prazo de expiração exp e uma assinatura sig, e o tempo efetivo de permanência em cache de uma resposta assinada é limitado pelo tempo restante de validade da assinatura.
Para respostas do Smart CDN, os cabeçalhos padrão documentados do Robot /file/serve incluem Accept-Ranges: bytes e um Content-Type obtido do tipo MIME detectado do arquivo.
Fontes
- RFC 9110: semântica HTTP (Content-Type, seção 8.3; solicitações de intervalo, seção 14)
- RFC 9111: armazenamento em cache HTTP (chaves de cache, seção 2)
- Cloudflare: chaves de cache e a chave de cache padrão
- Amazon CloudFront: entender a chave de cache
- Amazon CloudFront: como as solicitações parciais (solicitações GET por intervalo) são processadas
- Guia de conteúdo web do Apple Safari (arquivado): configurar seu servidor para solicitações de intervalos de bytes
- MDN: solicitações de intervalos HTTP
- RFC 8216: HTTP Live Streaming (URIs relativas em playlists, seção 4.1)
- RFC 3986: sintaxe genérica de URI (resolução de referências, seção 5.2.2)
- Amazon CloudFront: decidir entre URLs assinadas e cookies assinados
- RFC 8246: respostas HTTP imutáveis (URLs versionadas)
- MDN: cache HTTP (quebra de cache com URLs versionadas)