O Media CDN fornece recursos avançados de roteamento HTTP que permitem mapear o tráfego para origens e configurações de borda específicas em um nível detalhado.
Solicitações de correspondência
Uma configuração do Media CDN contém um conjunto de rotas definidas na seção
Roteamento
para um
recurso
EdgeCacheService
.
Essas rotas correspondem a solicitações com base em (pelo menos) um host. Para mais detalhes sobre como
o tráfego é direcionado para uma origem, consulte
HostRule
e PathMatcher
.
Cada rota pode definir a própria configuração de CDN, regravações, redirecionamentos, políticas CORS, cabeçalhos HTTP personalizados e mapeamento de origem.
As rotas podem compartilhar origens.
Por exemplo, é possível encaminhar solicitações de manifestos para uma origem específica e definir um TTL de cache de curta duração e uma política de armazenamento em cache negativo. As solicitações de segmentos podem ser divididas para outra origem usando cabeçalhos e parâmetros de consulta para detalhar tipos de manifesto ou usuários específicos.
O exemplo a seguir mostra como rotear solicitações que correspondem a um cabeçalho,
parâmetro de consulta e prefixo de caminho específicos para o host media.example.com
:
name: prod-service routing: hostRules: - hosts: - media.example.com pathMatcher: example_routes pathMatchers: - name: example_routes routeRules: - priority: 10 origin: staging-live-origin matchRules: - prefixMatch: /vod/ headerMatches: - headerName: "x-staging-client" presentMatch: true queryParameterMatches: - name: "live" exactMatch: "yes" routeAction: cdnPolicy: defaultTtl: 5s
Correspondência de caminho
O Media CDN é compatível com correspondência de caminho completa (exata), de prefixo e de caractere curinga. A correspondência de caminho pode ser combinada com a correspondência baseada em parâmetros de host, cabeçalho e consulta para criar regras de roteamento de solicitações detalhadas.
Veja a seguir três maneiras de fazer a correspondência em um caminho de URL.
Campo | Descrição | Exemplo |
---|---|---|
matchRules[].fullPathMatch
|
A condição fullPathMatch corresponde ao caminho completo do URL, que não inclui a string de consulta. Especifique barras finais, se relevante.
|
Uma rota com uma regra de correspondência de Uma |
matchRules[].prefixMatch
|
A condição prefixMatch corresponde ao prefixo do caminho do URL. Os URLs
que começam com a mesma string são correspondentes.
|
Uma rota com uma regra de correspondência de |
matchRules[].pathTemplateMatch
|
A condição pathTemplateMatch é compatível com operadores de caractere curinga, permitindo corresponder padrões de URL e segmentos de caminho complexos, bem como capturar variáveis nomeadas para reescrever URLs.
|
Uma rota com uma regra de correspondência de Tanto Para mais exemplos, consulte a seção de correspondência de padrão. |
Para mais detalhes, consulte a especificação da API para
MatchRule
.
Por exemplo, para corresponder a todas as solicitações que começam com /stream/
, crie uma regra de rota
semelhante a esta:
name: prod-service routing: hostRules: - hosts: - media.example.com - *.vod.example.com pathMatcher: example_routes pathMatchers: - name: example_routes routeRules: - priority: 1 matchRules: - prefixMatch: /stream/
Este exemplo inclui explicitamente a barra final na regra de correspondência:
- Uma solicitação para
media.example.com/stream/id/1234/hls/manifest.m3u8
corresponde a essa rota. - Uma solicitação para
media.example.com/stream-eu/id/4567/hls/manifest.m3u8
não corresponde a essa rota.
No segundo caso, o Media CDN retorna um erro HTTP 404
,
a menos que haja outra rota ou uma rota "pega-tudo"
configurada.
Para orientações sobre como a precedência funciona para rotas com prefixos semelhantes, consulte a seção prioridade e ordem da rota.
Correspondência de padrões (caractere curinga)
A correspondência de padrões permite corresponder várias partes de um URL, incluindo URLs parciais e sufixos (extensões de arquivo), usando a sintaxe de caracteres curinga.
Também é possível associar um ou mais componentes de caminho a variáveis nomeadas em um campo pathTemplateMatch
e depois se referir a essas variáveis ao reescrever o URL em um campo pathTemplateRewrite
. Isso permite reordenar e remover componentes de URL antes
que a solicitação seja enviada à origem.
O exemplo a seguir mostra como é possível fazer a correspondência em dois sufixos de URL diferentes:
# EdgeCacheService.routing.pathMatchers[] routeRules: - priority: 1 description: "Match video segments" matchRules: - pathTemplateMatch: "/**.ts" - pathTemplateMatch: "/**.m4s" origin: prod-video-storage
A sintaxe compatível inclui o seguinte:
Operador | Corresponde a | Exemplo |
---|---|---|
*
|
Corresponde a um único componente de caminho até o próximo separador de caminho: /
|
/videos/*/*/*.m4s corresponde a
/videos/123414/hls/1080p5000_00001.m4s .
|
**
|
Corresponde a zero ou mais segmentos de caminho. Se presente, precisa ser o último operador. |
/**.mpd corresponde a
/content/123/india/dash/55/manifest.mpd .
|
{name} or {name=*}
|
Uma variável nomeada que corresponde a um só segmento de caminho.
Corresponde a um único componente de caminho, até o próximo separador de caminho: |
/content/{format}/{lang}/{id}/{file}.vtt corresponde a
/content/hls/en-us/12345/en_193913.vtt e captura
format="hls" , lang="en-us" , id="12345"
e file="en_193913" como variáveis.
|
{name=videos/*}
|
Uma variável nomeada que corresponde a mais de um segmento de caminho. O componente do caminho correspondente a videos/* é capturado como a variável nomeada.
|
/videos/{language=lang/*}/* corresponde a /videos/lang/en/video.m4s e preenche a variável de caminho language com o valor lang/en .
|
{name=**}
|
Uma variável nomeada que corresponde a zero ou mais segmentos de caminho. Se presente, precisa ser o último operador. |
|
Observações:
- Se você não estiver reescrevendo um URL, use os operadores
*
e**
mais simples. - Ao usar variáveis para capturar componentes de caminho, nenhuma parte do URL que
não for capturada por uma variável não poderá ser referenciada em um
pathTemplateRewrite
subsequente. Para ver um exemplo, consulte a seção Como capturar variáveis de caminho. - Não é possível fazer referência a variáveis em um
pathTemplateRewrite
subsequente que não existam nopathTemplateMatch
na mesma rota. - As variáveis diferenciam maiúsculas de minúsculas.
{FORMAT}
,{forMAT}
e{format}
representam diferentes variáveis e valores. - É possível especificar até 10 operadores (caracteres curinga ou variáveis) em uma correspondência.
Os campos
pathTemplateMatch
epathTemplateRewrite
não podem exceder 255 caracteres.
Exemplo: correspondência em uma extensão de arquivo
O exemplo a seguir mostra um caso de uso comum para operadores de caractere curinga: corresponder todos os componentes de caminho até um sufixo.
Nesse caso, faça o seguinte:
- Busque manifestos de vídeo (playlists) terminados em
.m3u8
e.mpd
da origem do manifesto, aplicando um TTL curto (cinco segundos) a essas respostas, porque elas mudam regularmente. - Busque segmentos de vídeo que terminam em
.ts
e.m4s
na origem do segmento e aplique um TTL mais longo (de um dia) a essas respostas.
Essa abordagem é frequentemente empregada ao usar serviços de SSAI (Injeção de anúncios do lado do servidor) ou DAI (Inserção de anúncios dinâmicos) e para vídeos ao vivo em que o manifesto é atualizado em intervalos de alguns segundos.
A configuração a seguir demonstra como definir o roteamento de CDN de mídia para oferecer suporte a isso:
name: prod-service routing: hostRules: - hosts: - media.example.com pathMatcher: example_routes pathMatchers: - name: example_routes routeRules: # the first route only matches video manifests - priority: 1 matchRules: - pathTemplateMatch: "/**.m3u8" # "**" matches all path segments - pathTemplateMatch: "/**.mpd" origin: manifest-origin routeAction: cdnPolicy: cacheMode: FORCE_CACHE_ALL defaultTtl: 5s # the second route matches video segments, fetches them # from a separate origin server, caching them for a longer # duration (1 day). - priority: 2 matchRules: - pathTemplateMatch: "/**.ts" - pathTemplateMatch: "/**.m4s" origin: segment-origin routeAction: cdnPolicy: cacheMode: FORCE_CACHE_ALL defaultTtl: 86400s
Exemplo: capturar variáveis de caminho
O exemplo abaixo mostra como usar variáveis nomeadas para descrever um ou mais componentes de caminho.
Essas variáveis podem ser usadas em um pathTemplateRewrite
para reescrever o caminho antes
que a solicitação seja enviada à origem ou para tornar um pathTemplateMatch
complexo autodescritivo.
routing: hostRules: - hosts: - media.example.com pathMatcher: example_routes pathMatchers: - name: example_routes routeRules: - priority: 1 matchRules: # Matches a request of "/us/en/hls/123139139/segments/00001.ts" - pathTemplateMatch: "/{country}/{lang}/{format}/{id}/{file=**}" origin: my-origin routeAction: urlRewrite: # Rewrites to "/123139139/hls/segments/00001.ts" pathTemplateRewrite: "/{id}/{format}/{file}"
Em especial:
- Cada variável
{name}
captura um único segmento de caminho. Um segmento de caminho é composto por todos os caracteres entre um par de/
("barras") em um caminho de URL. - Uma variável
{name=**}
captura todos os segmentos de caminho restantes. Neste caso, ela corresponde asegments/00001.ts
emaster.m3u8
. - No
pathTemplateRewrite
na mesma rota, consulte algumas das variáveis capturadas nopathTemplateMatch
. Você omite explicitamente as variáveis{country}
e{lang}
porque elas não correspondem à estrutura de diretórios na origem.
Nesse exemplo, ocorre o seguinte:
- Um URL de solicitação recebida de
/us/en/hls/123139139/segment_00001.ts
corresponde apathTemplateMatch
e é reescrito em/123139139/hls/segment_00001.ts
antes de ser enviado à origem. - Um URL de solicitação de entrada de
/us/123139139/master.m3u8
não corresponde apathTemplateMatch
e recebe uma resposta HTTP404 (Not Found)
. - Um URL de solicitação recebida de
/br/es/dash/c966cbbe6ae3/subtitle_00001.vtt
também corresponde aopathTemplateMatch
e é reescrito em/c966cbbe6ae3/dash/subtitle_00001.vtt
antes de ser enviado à origem.
Para saber mais sobre a interoperabilidade da correspondência de caracteres curinga com a regravação de URL, consulte a seção substituições.
Correspondência de host
Cada serviço pode corresponder a vários nomes de host, sendo que cada um deles contém o próprio grupo de rotas (conhecidos como correspondências de caminho). No caso mais comum, todos os nomes de host de um serviço são mapeados para um único conjunto de rotas compartilhadas com uma única lista de hosts e uma única correspondência de caminho.
name: prod-service routing: hostRules: - hosts: - media.example.com - *.vod.example.com pathMatcher: example_routes pathMatchers: - name: example_routes routeRules: # list of routes for the configured hosts - priority: 999 matchRules: - prefixMatch: / origin: DEFAULT_ORIGIN
Os hosts que não correspondem recebem uma página HTTP 404
padrão. Para aceitar qualquer host,
inclua o caractere curinga *
como uma entrada hostRules[].hosts[]
.
Também é possível definir grupos de trajetos, por exemplo, por país ou ao vivo versus sob demanda. Como cada serviço tem uma única política de segurança, geralmente recomendamos ter um serviço para cada mercado (região geográfica) ou carga de trabalho que você tenha.
Observações:
- Os cabeçalhos de host (ou HTTP/2
:authority
) que contêm uma porta são implicitamente associados a um host configurado. Não é necessário especificar explicitamente as portas. - Se a solicitação for por HTTP, uma entrada
hostRules[].hosts[]
de*.vod.example.com
corresponderá aus.vod.example.com
eus.vod.example.com:80
. - Se a solicitação for por HTTPS (TLS), uma entrada
hostRules[].hosts[]
de*.vod.example.com
corresponderá aus.vod.example.com:443
.
Para mais detalhes, consulte a especificação da API para
HostRule
.
Correspondência de cabeçalhos e parâmetros de consulta
É possível configurar rotas para corresponder a nomes específicos de cabeçalho e parâmetro de consulta, além da presença de um valor de cabeçalho (prefixo, sufixo ou correspondência exata).
A correspondência de parâmetro de consulta e cabeçalho é lógica "AND". A solicitação precisa corresponder a todos os parâmetros de consulta e chaves de cabeçalho (e valores, se especificados) para corresponder à rota especificada.
Por exemplo, se você quiser rotear solicitações com um nome de campo de cabeçalho e um valor de cabeçalho específicos para uma origem chamada alternate-origin
, configure as condições de correspondência em routeRules[].matchRules[].headerMatches[]
:
name: prod-service routing: hostRules: - hosts: - media.example.com pathMatcher: example_routes pathMatchers: - name: example_routes routeRules: - priority: 1 origin: alternate-origin matchRules: - prefixMatch: "/videos/" headerMatches: - headerName: "x-device-name" exactMatch: "roku"
Neste exemplo, as solicitações com /videos/
no início do URL e o cabeçalho x-device-name: roku
correspondem a essa rota. As solicitações sem esse nome de
cabeçalho ou com um valor diferente não correspondem a essa rota.
Para mais detalhes, consulte a especificação da API para
HeaderMatch
.
Da mesma forma, para corresponder aos parâmetros de consulta, especifique um ou mais queryParameterMatches
da seguinte maneira:
name: prod-service routing: hostRules: - hosts: - media.example.com pathMatcher: example_routes pathMatchers: - name: example_routes routeRules: - priority: 1 origin: eu-live-origin-prod matchRules: - prefixMatch: "/videos/" queryParameterMatches: - name: "playback_type" exactMatch: "live" - name: "geo" exactMatch: "eu"
Neste exemplo, uma solicitação do cliente de
https://cdn.example.com/videos/1234/abcd/xyz.m3u8?playback_type=live&geo=eu
corresponde a essa rota.
Para mais detalhes, consulte a especificação da API para
QueryParameterMatcher
.
Definir uma rota "pega-tudo" (padrão)
Por padrão, o Media CDN retorna um erro HTTP 404 (Not Found)
se uma solicitação
não corresponder a nenhuma rota configurada.
Para configurar uma rota catch-all, para um determinado pathMatcher
(coleção de rotas), faça o seguinte:
- Crie uma
routeRule
com a prioridade mais baixa (número mais alto). Por exemplo, 999, que é a menor prioridade de rota possível. - Configure um
matchRule
com uma correspondência de prefixo de/
(corresponde a todos os caminhos de solicitação). - Configure (uma de)
origin
ouurlRedirect
na rota.
Por exemplo, para configurar uma rota "pega-tudo" que direcione todas as solicitações sem correspondência
para uma origem padrão chamada my-origin
, crie uma nova rota com priority: 999
e matchRules[].prefixMatch
de /
da seguinte maneira:
name: prod-service routing: hostRules: - hosts: - cdn.example.com pathMatcher: example_routes pathMatchers: - name: example_routes routeRules: - priority: 999 origin: my-origin matchRules: - prefixMatch: /
Como opção, é possível reescrever o URL antes da busca da origem ou redirecionar para uma página padrão (como sua página de destino), em vez de enviar a solicitação "no estado em que se encontra" para a origem.
Prioridade e ordem de rotas
Cada rota em uma matriz de routeRules[]
precisa ter um priority
associado a ela.
Rotas mais específicas devem ser definidas com prioridade mais alta (número menor). Uma rota correspondente a um prefixo de /stream/
com prioridade 1 impede que uma rota mais específica de /stream/live/eu/
com prioridade 5 corresponda a qualquer solicitação.
- A rota com maior prioridade é "1" e a mais baixa é "999".
- Não é possível configurar duas ou mais routeRules com a mesma prioridade. A prioridade de cada regra precisa ser definida como um número entre 1 e 999.
- A definição de uma rota "pega-tudo" permite enviar todas as solicitações não correspondentes para uma origem padrão ou redirecioná-las para uma página de destino ou endpoint.
No exemplo a seguir, você pode ver que a rota /live/us/
nunca seria
correspondida porque a rota /live/
tem uma prioridade mais alta:
routeRules: - priority: 1 description: "Live routes" matchRules: - prefixMatch: /live/ routeAction: cdnPolicy: defaultTtl: 5s - priority: 2 description: "U.S based live streams" matchRules: # This would never be matched, as the /live/ prefixMatch at priority 1 # would always take precedence. - prefixMatch: /live/us/ routeAction: cdnPolicy: defaultTtl: 5s - priority: 999 description: "Catch-all route" matchRules: - prefixMatch: /
Para resolver isso, você coloca a rota mais específica (mais longa) com uma prioridade mais alta:
routeRules: - priority: 1 description: "U.S based live streams" matchRules: # The more specific (longer) match is at a higher priority, and now # matches requests as expected. - prefixMatch: /live/us/ routeAction: cdnPolicy: defaultTtl: 5s - priority: 2 description: "Live routes" matchRules: - prefixMatch: /live/ routeAction: cdnPolicy: defaultTtl: 5s - priority: 999 description: "Catch-all route" matchRules: - prefixMatch: /
Isso permite que a rota mais específica corresponda às solicitações corretamente. Uma solicitação prefixada com /live/eu/
ainda seguiria para a rota /live/
com prioridade 2.
Filtragem de métodos
Por padrão, o Media CDN faz o proxy apenas dos métodos GET
, HEAD
e OPTIONS
para sua origem e filtra os métodos que podem modificá-la.
Na Visualização, é possível substituir esse comportamento
padrão para uma regra de rota específica especificando os métodos que você quer
colocar em proxy para sua origem. Além de GET
, HEAD
e OPTIONS
,
o Media CDN é compatível com PUT
, POST
, DELETE
e PATCH
.
Para configurar o suporte a um conjunto de métodos para uma regra de rota, especifique uma
seção routeMethods
que tenha um valor allowed_methods
para cada método.
routeRules: - priority: 5 description: "Video uploads" routeMethods: allowedMethods: ["PUT", "POST", "OPTIONS"] matchRules: - pathTemplateMatch: "/uploads/**.ts" origin: prod-video-storage - priority: 10 description: "Video serving" routeMethods: allowedMethods: ["GET", "HEAD"] matchRules: - pathTemplateMatch: "/videos/**.ts" origin: prod-video-storage
No pré-lançamento, o Media CDN permite atualizar e visualizar essa
configuração usando a API Network Services v1alpha1.
Também é possível usar os comandos gcloud alpha edge-cache services export
e gcloud alpha edge-cache services import
para atualizar os arquivos YAML de configuração de serviço.
Normalização de caminho
A normalização de caminho descreve como o Media CDN combina várias representações de um URL em uma única representação canônica em cenários específicos.
A normalização de caminho pode melhorar diretamente as taxas de ocorrência em cache, reduzindo o número de URLs de solicitação que representam o mesmo conteúdo e atenuando erros de origem para origens que esperam caminhos normalizados.
As solicitações recebidas são normalizadas da seguinte maneira:
- Várias barras consecutivas são mescladas em uma única barra. Por exemplo, um
caminho de URL de
/videos///12345/manifest.mpd
é normalizado para/videos/12345/manifest.mpd
. - Os segmentos de caminho são normalizados de acordo com a seção 6.2.2.3 do RFC 3986 (em inglês).
Por exemplo, o caminho
/a/b/c/./../../g
é normalizado para/a/g
com base no algoritmo "remove dot segments" definido na RFC 3986. Essa normalização acontece antes de verificar o cache ou encaminhar a solicitação para a origem. - As solicitações não são normalizadas com codificação percentual. Por exemplo, um URL com um caractere de barra codificado por porcentagem (
%2F
) não é decodificado no formulário não codificado.
Os URLs diferenciam maiúsculas de minúsculas e não são normalizados. Muitos URLs contêm codificações base64 que diferenciam maiúsculas de minúsculas, incluindo URLs com tokens de solicitação assinada.
Regravações e redirecionamentos
As seções a seguir fornecem exemplos sobre como reescrever solicitações e configurar redirecionamentos.
Reescrever URLs de solicitação
O Media CDN oferece suporte a substituições de host e caminho. As regravações mudam o URL enviado à origem e permitem modificar hosts e caminhos conforme necessário. As substituições de host e caminho estão no nível da rota, permitindo definir quais solicitações específicas são reescritas com base em qualquer correspondente, incluindo caminho, parâmetro de consulta e cabeçalho da solicitação.
Para mais detalhes, consulte a especificação da API para
RouteAction.UrlRewrite
.
Veja a seguir três maneiras de reescrever uma solicitação:
Campo | Descrição |
---|---|
urlRewrite.pathPrefixRewrite
|
Regrava o caminho, removendo o prefixo especificado no
Só é possível especificar |
urlRewrite.pathTemplateRewrite
|
Só é possível especificar |
urlRewrite.hostRewrite
|
Regrava o host antes que a solicitação seja enviada ao servidor de origem. |
Observações:
- Os URLs regravados não alteram a chave de cache. A chave de cache é baseada no URL de solicitação enviado pelo cliente.
- A regravação ocorre após a correspondência de rota e a validação da solicitação assinada. As rotas não são recombinadas com outra regra de correspondência.
Exemplo: remover um prefixo de caminho
Por exemplo, para reescrever um URL de solicitação do cliente de /vod/videos/hls/1234/abc.ts
para /videos/hls/1234/abc.ts
(removendo /vod
do caminho), use o recurso pathPrefixRewrite
:
name: prod-service routing: hostRules: - hosts: - cdn.example.com pathMatcher: example_routes pathMatchers: - name: example_routes routeRules: - priority: 1 origin: my-origin matchRules: - prefixMatch: "/vod/videos/" routeAction: urlRewrite: pathPrefixRewrite: "/videos/"
Um pathPrefixRewrite
substitui todo o componente do caminho correspondente ao
matchRules[].prefixMatch
pelo valor de pathPrefixRewrite
.
Para reescrever um nome de host (por exemplo, reescrever cdn.example.com
em
my-bucket.s3.us-west-2.amazonaws.com
), configure o seguinte:
name: prod-service routing: hostRules: - hosts: - cdn.example.com pathMatcher: example_routes pathMatchers: - name: example_routes routeRules: - priority: 1 origin: my-origin matchRules: - prefixMatch: "/videos/" routeAction: urlRewrite: hostRewrite: "my-bucket.s3.us-west-2.amazonaws.com"
Nesse caso, o URL da solicitação de origem mudaria de
cdn.example.com/videos/*
para my-bucket.s3.us-west-2.amazonaws.com/videos/*
.
Também é possível combinar substituições de host e caminho em uma única rota.
Exemplo: usar variáveis para reescrever URLs
Para usar pathTemplateMatch
e pathTemplateRewrite
para reescrever partes de um URL de solicitação recebida, consulte a seção Como capturar variáveis.
Solicitações de redirecionamento
O Media CDN é compatível com três tipos de redirecionamentos:
- Redirecionamentos de host, que redirecionam apenas o host (domínio), mantendo o caminho e os parâmetros de consulta inalterados.
- Redirecionamentos de caminho, que substituem o caminho completo.
- Redirecionamentos de prefixo de caminho, que substituem apenas o prefixo correspondente.
Redireciona por padrão para HTTP 301 (Moved Permanently)
, mas pode ser configurado para retornar diferentes códigos de status de redirecionamento por rota.
A configuração a seguir é um exemplo de redirecionamento baseado em prefixo,
em que você redireciona os usuários que visitam https://cdn.example.com/on-demand/*
para
https://cdn.example.com/streaming/*
.
name: prod-service routing: hostRules: - hosts: - cdn.example.com pathMatcher: example_routes pathMatchers: - name: example_routes routeRules: - priority: 10 matchRules: - prefixMatch: "/on-demand/" urlRedirect: # The prefix matched in matchRules.prefixMatch is replaced # by this value prefixRedirect: "/streaming/" redirectResponseCode: TEMPORARY_REDIRECT # corresponds to a HTTP 307
Este exemplo também altera o redirecionamento para um redirecionamento temporário, o que impede que clientes (como navegadores) o armazenem em cache. Isso pode ser útil se você pretende mudar em breve.
Os valores redirectResponseCode
compatíveis são mostrados na tabela a seguir.
Redirecionar o código de resposta | Código de status HTTP |
---|---|
MOVED_PERMANENTLY_DEFAULT |
HTTP 301 (movido permanentemente) |
FOUND |
HTTP 302 (encontrado) |
SEE_OTHER |
HTTP 303 (Consultar outro) |
TEMPORARY_REDIRECT |
HTTP 307 (redirecionamento temporário) |
PERMANENT_REDIRECT |
HTTP 308 (redirecionamento permanente) |
Observações:
- Uma rota pode direcionar o tráfego para uma origem ou retornar um redirecionamento para o cliente. Não é possível definir os campos
origin
eurlRedirect
ao mesmo tempo. - As rotas que redirecionam para HTTPS exigem que pelo menos um certificado SSL esteja anexado ao serviço.
Para mais detalhes, consulte a especificação da API para
RouteRule.UrlRedirect
.
Redirecionar todas as solicitações para HTTPS
Para redirecionar todas as solicitações para HTTPS (em vez de HTTP), configure cada um dos
serviços para redirecionar automaticamente todas as solicitações de clientes para HTTPS. Os clientes que se conectam por HTTP recebem uma resposta 301 (Permanent Redirect)
HTTP com o cabeçalho Location
definido para o mesmo URL usando "https://" em vez de "http://".
gcloud
gcloud edge-cache services update MY_SERVICE \ --require-tls
Request issued for: [MY_SERVICE] Updated service [MY_SERVICE].
O comando retorna uma descrição do serviço, com requireTls
agora definido
como true
.
name: MY_SERVICE requireTls: true
Também é possível definir o cabeçalho Strict-Transport-Security como um cabeçalho de resposta para direcionar os clientes a sempre se conectarem diretamente por HTTPS.
Usar back-ends de armazenamento de terceiros
O Media CDN oferece suporte à conexão com endpoints HTTP acessíveis publicamente fora do Google Cloud, incluindo buckets de armazenamento da AWS S3, armazenamento de blobs do Azure e outros provedores de armazenamento. Isso pode ser útil se você tiver uma arquitetura de multicloud ou ainda não migrar dados para o Cloud Storage usando o Serviço de transferência do Cloud Storage.
Uma configuração de origem mínima que configura um bucket hospedado virtual no AWS S3:
name: MY_S3_ORIGIN originAddress: BUCKET-NAME.s3.REGION.amazonaws.com
Se você não estiver usando um nome de bucket que corresponda aos nomes de host configurados para seus recursos EdgeCacheService
, também precisará configurar uma regravação de host para rotas associadas a essa origem (ou origens). Caso contrário, o cabeçalho Host definido pela
solicitação do cliente será usado ao fazer a busca na origem.
Por exemplo, se quiser mapear todas as solicitações com um prefixo de caminho /legacy/
para o
bucket externo, configure um hostRewrite
e um
pathPrefixRewrite
para remover esse prefixo da solicitação de origem:
routeRules: - description: legacy backend matchRules: - prefixMatch: "/legacy/" routeAction: urlRewrite: hostRewrite: BUCKET-NAME.s3.REGION.amazonaws.com pathPrefixRewrite: / cdnPolicy: cacheMode: CACHE_ALL_STATIC defaultTtl: 3600s
Para mais informações sobre como o cabeçalho do host é definido em solicitações de origem, consulte a documentação de cabeçalhos de solicitação de origem.
Compartilhamento de recursos entre origens (CORS, na sigla em inglês)
O Compartilhamento de recursos entre origens (CORS, na sigla em inglês) é uma abordagem focada no navegador para fazer solicitações entre origens com segurança.
As políticas do CORS permitem definir automaticamente cabeçalhos do CORS, como Access-Control-Allow-Origins
, com base em uma política por rota.
Configurar o CORS
O Media CDN permite definir uma política de CORS em uma rota para um
EdgeCacheService
.
Uma política CORS define essas regras com um conjunto comum de cabeçalhos HTTP. É possível
definir cabeçalhos CORS comuns nas respostas, como
Access-Control-Allow-Origin
, Access-Control-Max-Age
e Access-Control-Allow-Headers
. Esses cabeçalhos permitem fazer
chamadas entre origens para os serviços do Media CDN que podem ser
hospedados em um domínio diferente (origem) do front-end do site e podem
impedir solicitações entre origens que você não permite explicitamente.
Por exemplo, player.example.com
e api.example.com
são origens diferentes
(no sentido do navegador) e é recomendável que seu aplicativo de front-end
faça solicitações a api.example.com
para buscar a próxima playlist ou atualizar uma
lista de conteúdo relacionado. Da mesma forma, player.example.com
pode precisar
entrar em contato com cdn.example.com
para buscar playlists e segmentos de vídeo:
cdn.example.com
precisa indicar que está tudo certo e que
player.example.com
é um allowed origin
, bem como qualquer outra regra
(cabeçalhos permitidos, se os cookies podem ser incluídos).
Para usar outro exemplo, se você quiser permitir stream.example.com
como uma origem e um cabeçalho X-Client-ID
em solicitações de CORS, configure um corsPolicy
em uma rota da seguinte maneira:
corsPolicy: maxAge: 600 allowOrigins: ["stream.example.com"] allowHeaders: ["X-Client-ID"]
Um corsPolicy
é configurado em
routing.pathMatchers[].routeRules[].routeAction.corsPolicy
em um
EdgeCacheService. Cada routeRule
pode definir um corsPolicy
diferente, conforme
necessário, ou nenhum.
Se você definir um valor corsPolicy
e também definir um cabeçalho de resposta personalizado usando os campos responseHeadersToAdd
em uma rota com o mesmo nome, o cabeçalho de resposta personalizado terá precedência e será usado no lugar do valor corsPolicy
.
Se a resposta de origem definir cabeçalhos HTTP e você tiver um valor corsPolicy
definido, os valores corsPolicy
serão usados. Os valores não são recolhidos
ou combinados para evitar o envio de valores de cabeçalho inválidos a um cliente ou
a definição não intencional de uma política mais permissiva do que o pretendido.
O {origin_request_header}
especial é preenchido com o cabeçalho HTTP Origin
na solicitação do cliente. Isso pode ser definido como um valor de cabeçalho de resposta personalizado em uma rota para o cabeçalho Access-Control-Allow-Origin
.
Para mais detalhes, consulte a especificação
da API para
RouteAction.CORSPolicy
.
Campos da política do CORS
A tabela a seguir descreve os campos que uma política de CORS contém.
Campo | Descrição | Exemplo |
---|---|---|
allowOrigins |
Define o cabeçalho de resposta
Por exemplo, se o conteúdo do vídeo for veiculado em |
Access-Control-Allow-Origins: https://stream.example.com
|
maxAge |
Define o cabeçalho de resposta Alguns navegadores limitam isso a duas horas ou menos, mesmo que o valor máximo (86.400s) seja especificado. |
Access-Control-Max-Age: 7200
|
allowMethods |
Define o cabeçalho de resposta Por padrão, o Media CDN é compatível apenas com os métodos |
Access-Control-Allow-Methods: GET, OPTIONS, HEAD
|
allowHeaders |
Define o cabeçalho Geralmente, isso é exigido por players de vídeo, que precisam acessar alguns cabeçalhos de resposta para conteúdo de vídeo ao solicitá-lo de origem cruzada. |
Access-Control-Allow-Headers: Content-Type, If-Modified-Since,
Range, User-Agent
|
exposeHeaders |
Define o cabeçalho de resposta Geralmente, isso é exigido por players de vídeo, que podem precisar acessar cabeçalhos de resposta específicos para conteúdo de vídeo ao solicitar conteúdo de origem cruzada. |
Access-Control-Expose-Headers: Date, Cache-Status, Content-Type,
Content-Length
|
allowCredentials |
Define o cabeçalho de resposta Esse cabeçalho é omitido quando definido como falso. |
Access-Control-Allow-Credentials: true
|
disabled |
Desativa o corsPolicy sem removê-lo. As solicitações OPTIONS
de simulação são encaminhadas por proxy para a origem.
|
N/A |
Exemplo de corsPolicy
O exemplo de configuração a seguir mostra uma configuração corsPolicy
básica:
routeRules: - priority: 1 matchRules: - prefixMatch: /stream/ routeAction: cdnPolicy: defaultTtl: 3600s corsPolicy: allowOrigins: - "https://stream.example.com" - "https://stream-staging.example.com" maxAge: 86400s # some browsers might only honor up to 7200s or less allowMethods: - "GET" - "HEAD" - "OPTIONS" allowHeaders: - "Content-Type" - "If-Modified-Since" - "Range" - "User-Agent" exposeHeaders: - "Content-Type" - "Content-Length" - "Date"
Resolver problemas de roteamento
Se algumas solicitações não recuperarem resultados correspondentes ou retornarem erros, verifique o seguinte:
- Uma rota precisa ter um
matchRule
com exatamente um dos valoresprefixMatch
,fullPathMatch
oupathTemplateMatch
definido. A API retornará um erro se você não incluir um desses campos. - Verifique se o
priority
de cada rota está definido corretamente: rotas mais específicas (mais longas) precisam receber uma prioridade mais alta sobre correspondências de rota mais curtas e amplas. - Por padrão, apenas as solicitações
GET
,HEAD
eOPTIONS
são aceitas. Em Visualização, para configurar a compatibilidade com outros métodos, consulte Métodos de rota. Os métodos que não estão ativados para uma rota específica são rejeitados com um erro HTTP405 (Method Not Allowed)
. - As solicitações HTTP
GET
com corpo ou qualquer solicitação com trailers são rejeitadas com um erro HTTP400
, porque os corpos da solicitação não são permitidos em solicitaçõesGET
. - A correspondência de parâmetro de consulta e cabeçalho é lógica "AND". A solicitação precisa corresponder a todos os parâmetros de consulta ou chaves de cabeçalho (e valores, se especificados) para corresponder à rota especificada.
A seguir
- Analise a documentação sobre como configurar o armazenamento em cache.
- Entenda como se conectar a origens diferentes.
- Configure os certificados TLS (SSL) do serviço.
- Configure solicitações assinadas para autenticar o acesso ao conteúdo.