Configurar rotas de serviço

O Media CDN oferece recursos avançados de roteamento HTTP mapear o tráfego para origens e configurações de borda específicas nível

Solicitações de correspondência

Uma configuração do Media CDN contém um conjunto de rotas definidas na Roteamento para um EdgeCacheService recurso. Essas rotas correspondem a solicitações com base em (pelo menos) um host. Para mais detalhes sobre como tráfego for direcionado para uma origem, consulte HostRule e PathMatcher. Cada rota pode definir a própria configuração, regravações, redirecionamentos Políticas CORS, cabeçalhos HTTP personalizados e mapeamento de origem. As rotas podem compartilhar origens.

Por exemplo, você pode encaminhar solicitações de manifestos para uma origem específica e defina um TTL de cache de curta duração e um política de armazenamento em cache negativo. As solicitações de segmentos podem ser divididas em 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 específico, parâmetro de consulta e prefixo de caminho do 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 um host, um cabeçalho e uma consulta com base em parâmetros para criar regras detalhadas de roteamento de solicitações.

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. Você deve especificar valores barras, se relevante.

Uma rota com uma regra de correspondência de fullPathMatch: "/stream/" corresponde a /stream/, mas não a /stream, ou /stream/us/hls/1234.ts.

Uma fullPathMatch é uma correspondência explícita (exata).
matchRules[].prefixMatch A condição prefixMatch corresponde ao prefixo do caminho do URL. URLs que começam com a mesma correspondência de string.

Uma rota com uma regra de correspondência de prefixMatch: "/videos/" corresponde tanto a /videos/hls/58481314/manifest.m3u8 quanto /videos/dash porque ambas contêm o /videos/ .
matchRules[].pathTemplateMatch A condição pathTemplateMatch oferece suporte operadores de caractere curinga, permitindo corresponder padrões de URL complexos e caminhos e capturar variáveis nomeadas para reescrever URLs.

Uma rota com uma regra de correspondência de pathTemplateMatch: "/**.m3u8" corresponde a qualquer fim de caminho de URL com .m3u8.

Tanto /content/en-GB/13/51491/manifest_193193.m3u8 quanto /p/abc/1234/manifest_1080p5000.m3u8 correspondem a esse padrão.

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:

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 esse trajeto.
  • Fazer uma solicitação para media.example.com/stream-eu/id/4567/hls/manifest.m3u8 não correspondem a este trajeto.

No segundo caso, o Media CDN retorna um erro HTTP 404. a menos que houvesse outro trajeto ou uma rota geral configurada.

Para orientações sobre como a predecência funciona para trajetos com prefixos semelhantes, consulte a seção de 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.

Você também pode associar um ou mais componentes de caminho a variáveis nomeadas em uma pathTemplateMatch e depois se referir a essas variáveis ao reescrever o URL no um campo pathTemplateRewrite. Isso permite reordenar e remover componentes de URL antes a solicitação é enviada à sua 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 correspondências /videos/123414/hls/1080p5000_00001.m4s.
** Corresponde a zero ou mais segmentos de caminho. Se presente, precisa ser o último operador. /**.mpd correspondências /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 correspondências /content/hls/en-us/12345/en_193913.vtt e captura format="hls", lang="en-us" e 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 o videos/* correspondente é capturado como a variável nomeada. /videos/{language=lang/*}/* correspondências /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.

/**.m3u8 ou /{path=**}.m3u8 corresponde a todos até a extensão.

/videos/{file=**} correspondências /videos/en-GB/def566/manifest.m3u8, incluindo o e captura a variável de caminho file="en-GB/def566/manifest.m3u8

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, qualquer parte do URL que não forem capturadas por uma variável não poderão ser referenciadas em uma pathTemplateRewrite: Para ver um exemplo, consulte seção captura de variáveis de caminho.
  • Não é possível fazer referência a variáveis em uma pathTemplateRewrite subsequente que não existem no pathTemplateMatch no mesmo trajeto.
  • As variáveis diferenciam maiúsculas de minúsculas, com {FORMAT}, {forMAT} e {format} que representam diferentes variáveis e valores.
  • É possível especificar até 10 operadores (caracteres curinga ou variáveis) em uma correspondência. Os campos pathTemplateMatch e pathTemplateRewrite 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: correspondência todos os componentes do caminho até um sufixo.

Nesse caso, faça o seguinte:

  • Buscar manifestos de vídeo (playlists) que terminam em .m3u8 e .mpd no do manifesto, aplicando um TTL curto (cinco segundos) a essas respostas porque mudam regularmente.
  • busca segmentos de vídeo que terminam em .ts e .m4s na origem do segmento; aplicar um TTL mais longo (um dia) a essas respostas.

Essa abordagem é frequentemente empregada ao usar injeção de anúncios do lado do servidor (SSAI, na sigla em inglês) ou Serviços de Inserção de anúncios dinâmicos (DAI) e para vídeos ao vivo em que o manifesto é atualizados em intervalos de alguns segundos.

A configuração a seguir demonstra como definir seu Roteamento do Media CDN para dar 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 a seguir mostra como usar variáveis nomeadas para descrever uma ou mais componentes de caminho.

Essas variáveis podem ser usadas em um pathTemplateRewrite para reescrever o caminho anterior. à solicitação enviada à origem ou para fazer uma solicitação pathTemplateMatch 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}"

Especificamente:

  • Cada variável {name} captura um único segmento de caminho. Um segmento de caminho é caracteres entre um par de / ("barras") em um caminho de URL.
  • Uma variável {name=**} captura todos os segmentos de caminho restantes. neste caso, isso corresponde a segments/00001.ts e master.m3u8.
  • No pathTemplateRewrite no mesmo trajeto, você consulta algumas das variáveis capturadas no pathTemplateMatch. Você explicitamente omitir as variáveis {country} e {lang} porque elas não correspondem à na origem.

Nesse exemplo, ocorre o seguinte:

  • Há uma correspondência entre o URL de solicitação recebida de /us/en/hls/123139139/segment_00001.ts o pathTemplateMatch e é reescrito /123139139/hls/segment_00001.ts antes de serem enviados à origem.
  • Um URL de solicitação recebida de /us/123139139/master.m3u8 não corresponde à pathTemplateMatch e recebe uma resposta HTTP 404 (Not Found).
  • Um URL de solicitação recebida de /br/es/dash/c966cbbe6ae3/subtitle_00001.vtt também corresponde ao pathTemplateMatch e é reescrito para /c966cbbe6ae3/dash/subtitle_00001.vtt antes de serem enviados à origem.

Para saber mais sobre a interoperabilidade da correspondência de caracteres curinga com a regravação de URLs, consulte a seção rewrites.

Correspondência de host

Cada serviço pode corresponder a vários nomes de host, sendo que cada conjunto contém um grupo próprio 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 um único 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 organizador, é possível incluir o caractere curinga * como uma entrada hostRules[].hosts[].

Você também pode definir grupos de trajetos (por exemplo, agrupar por país ou e não sob demanda). Como cada serviço tem uma única política de segurança, geralmente recomendam ter um serviço para cada mercado (região geográfica) ou carga de trabalho que você tem.

Observações:

  • Os cabeçalhos de host (ou HTTP/2 :authority) que contêm uma porta são implicitamente correspondentes a um host configurado. Não é preciso especificar explicitamente ports.
  • Se a solicitação for por HTTP, uma entrada hostRules[].hosts[] de *.vod.example.com corresponde a us.vod.example.com e us.vod.example.com:80.
  • Se a solicitação for por HTTPS (TLS), uma entrada hostRules[].hosts[] de *.vod.example.com corresponde a us.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 parâmetros de consulta e cabeçalhos, bem como a presença de um valor de cabeçalho (prefixo, sufixo ou correspondência exata).

O parâmetro de consulta e a correspondência de cabeçalho têm um "AND" lógico—a solicitação deve corresponder todos os parâmetros de consulta e chaves de cabeçalho (e valores, se especificados) para corresponder do trajeto especificado.

Por exemplo, se você quiser rotear solicitações com um nome de campo de cabeçalho específico e para uma origem chamada alternate-origin, configure a correspondência condições 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, solicitações com /videos/ no início do URL e o O cabeçalho x-device-name: roku corresponde a esse trajeto. Solicitações sem esse cabeçalho ou com um valor diferente não correspondem a esse trajeto.

Para mais detalhes, consulte a especificação da API para HeaderMatch.

Da mesma forma, para fazer correspondência com os 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 esta 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 corresponde a nenhuma rota configurada.

Para configurar uma rota pega-tudo, 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.
  • Configurar um matchRule com um prefixo correspondente a / (corresponde a todas as solicitações) caminhos).
  • Configure (uma de) origin ou urlRedirect 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 um matchRules[].prefixMatch de / desta 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: /

É possível reescrever o URL antes da busca da origem ou redirecionar para um página padrão (como a página de destino) em vez de enviar a solicitação "no estado em que se encontra" à origem.

Prioridade e ordem de rotas

Cada trajeto em uma matriz de routeRules[] precisa ter um priority associado a reimplantá-lo.

Rotas mais específicas devem ser definidas com prioridade mais alta (número menor). Um que corresponda a um prefixo de /stream/ com prioridade 1. Caso contrário, uma rota mais específica de /stream/live/eu/ com prioridade 5, para não corresponder a solicitações.

  • A rota com maior prioridade é "1" e a mais baixa é "999".
  • Não é possível configurar duas ou mais routeRules com a mesma prioridade. Prioridade de cada regra deve ser definido como um número entre 1 e 999.
  • Definir uma rota "pega-tudo" permite que você envie todos solicitações não correspondentes para uma origem padrão ou redirecionamento a uma página de destino ou endpoint.

No exemplo a seguir, é possível ver que a rota /live/us/ nunca seria correspondidos porque a rota /live/ está em 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 prefixado com /live/eu/ ainda seguiria para a rota /live/ em prioridade 2.

Filtragem de métodos

Por padrão, o Media CDN faz o proxy somente de GET, HEAD e OPTIONS à sua origem e filtra os métodos que podem modificá-la.

Em Visualização, você pode substituir esse padrão para uma regra de rota específica especificando os métodos que você faria por exemplo, proxy para sua origem. Além de GET, HEAD e OPTIONS, O Media CDN oferece suporte a PUT, POST, DELETE e PATCH.

Para configurar o suporte para um conjunto de métodos para uma regra de rota, especifique um Seção routeMethods que tem 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

Em "Pré-lançamento", o Media CDN permite atualizar e visualizar usando a API Network Services v1alpha1. Se preferir, use o comando gcloud alpha edge-cache services export. e o comando 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ários de um URL em uma única representação canônica em uma diferentes.

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, O caminho do URL de /videos///12345/manifest.mpd é normalizado para /videos/12345/manifest.mpd.
  • Os segmentos do caminho são normalizados de acordo com a Seção 6.2.2.3 do RFC 3986. Por exemplo, o caminho /a/b/c/./../../g é normalizado para /a/g com base no as "remover segmentos de pontos" algoritmo definido na RFC 3986. Essa normalização ocorre antes de verificar 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 o caractere de barra codificado por porcentagem (%2F) não é decodificado na forma

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 substituições mudam a URL enviado à origem que permite modificar hosts e caminhos conforme necessário. Hospedar e regravações de caminho são feitas no nível da rota, permitindo que você defina quais solicitações reescritos com base em qualquer correspondente, incluindo caminho, parâmetro de consulta e solicitação cabeçalho.

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 prefixMatch que correspondeu à solicitação.

Apenas um: pathPrefixRewrite ou pathTemplateRewrite pode ser especificado em uma única regra de rota.

urlRewrite.pathTemplateRewrite

pathTemplateRewrite só pode ser usado com uma regra de correspondência pathTemplateMatch correspondente na mesma rota.

Apenas um: pathPrefixRewrite ou pathTemplateRewrite pode ser especificado em uma única regra de rota.

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 tem como base o 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. Trajetos não são correspondentes novamente a 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), será possível usar 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 a matchRules[].prefixMatch com o valor de pathPrefixRewrite.

Para reescrever um nome do host, por exemplo, reescrever cdn.example.com para my-bucket.s3.us-west-2.amazonaws.com), é possível configurar 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 uma URL de solicitação de entrada, consulte as variáveis de captura nesta seção.

Solicitações de redirecionamento

O Media CDN é compatível com três tipos de redirecionamentos:

  • Redirecionamentos de host, que redirecionam somente o host (domínio), mantendo o caminho e 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 retornam códigos de status de redirecionamento diferentes por trajeto.

A configuração a seguir é um exemplo de redirecionamento baseado em prefixo, para onde 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 (como navegadores) armazenam os dados em cache. Isso pode ser útil se você espera alterá-la em um futuro próximo.

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 para o cliente. Não é possível definir origin e urlRedirect ao mesmo tempo ao mesmo tempo.
  • As rotas que redirecionam para HTTPS exigem que pelo menos um certificado SSL está anexado à 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 seus serviços para redirecionar automaticamente todas as solicitações de clientes para HTTPS. Clientes se conectando por HTTP recebem uma resposta 301 (Permanent Redirect) HTTP com o Cabeçalho Location definido como 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 definido. para true.

  name: MY_SERVICE
  requireTls: true

Também é possível definir Strict-Transport-Security como cabeçalho de resposta para que clientes diretos sempre se conectem diretamente por HTTPS.

Usar back-ends de armazenamento de terceiros

O Media CDN oferece suporte à conexão com HTTP disponível endpoints fora do Google Cloud, incluindo buckets de armazenamento da AWS S3, Azure Blob Storage e outros provedores de armazenamento. Isso pode ser útil se você tiver um multicloud ou ainda não migraram dados para o Cloud Storage usando o Serviço de transferência do Cloud Storage.

Uma configuração mínima de origem que define uma bucket com hospedagem virtual no AWS S3:

name: MY_S3_ORIGIN
originAddress: BUCKET-NAME.s3.REGION.amazonaws.com

Se você não usar um nome de bucket que corresponda aos nomes de host configurados para sua EdgeCacheService, também é necessário configurar uma regravação de host para rotas associados a essa origem (ou origens). Caso contrário, o cabeçalho Host definido pelo solicitação do cliente é usada ao buscar a origem.

Por exemplo, se você quiser mapear todas as solicitações com um prefixo de caminho /legacy/ para sua em um bucket externo, é possível configurar 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 nas solicitações de origem, consulte os cabeçalhos da solicitação de origem; na documentação do Google Cloud.

Compartilhamento de recursos entre origens (CORS, na sigla em inglês)

Compartilhamento de recursos entre origens (CORS) é uma abordagem centrada no navegador para fazer solicitações entre origens com segurança. As políticas do CORS permitem que você defina automaticamente cabeçalhos 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. Você pode definir cabeçalhos CORS comuns em respostas, como Access-Control-Allow-Origin, Access-Control-Max-Age. e Access-Control-Allow-Headers. Esses cabeçalhos permitem que você faça chamadas de origem cruzada aos serviços do Media CDN que possam ser hospedados em um domínio diferente (origem) do front-end do seu site e podem evitar solicitações de origem cruzada que você não permite de forma explícita.

Por exemplo, player.example.com e api.example.com são origens diferentes (no sentido do navegador), e talvez você queira que seu aplicativo de front-end faça solicitações a api.example.com para buscar a próxima lista de reprodução ou atualizar uma listagem de conteúdo relacionado. Da mesma forma, player.example.com pode precisar Entre em contato com cdn.example.com para buscar playlists de vídeo e segmentos de vídeo: cdn.example.com precisa indicar que está tudo certo e que A player.example.com é um allowed origin, assim 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 origem e um cabeçalho X-Client-ID em solicitações CORS, é possível configurar corsPolicy em uma da seguinte forma:

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árias ou nenhuma.

Se você definir um valor corsPolicy e também um cabeçalho de resposta personalizado usando usando os campos responseHeadersToAdd em um trajeto com o mesmo nome, o o cabeçalho de resposta personalizada tem precedência e é usado no lugar do Valor de 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 estão recolhidos ou combinados para evitar o envio de valores de cabeçalho inválidos a um cliente ou configurar involuntariamente 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 um rota para o cabeçalho Access-Control-Allow-Origin.

Para mais detalhes, consulte a API especificação 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 Access-Control-Allow-Origins. que especifica quais origens podem fazer solicitações entre origens em um do navegador.

Por exemplo, se o conteúdo de vídeo for veiculado de https://video.example.com, mas seu portal voltado ao usuário é veiculado de https://stream.example.com, adicione https://stream.example.com como uma origem permitida.

Access-Control-Allow-Origins: https://stream.example.com
maxAge

Define o cabeçalho de resposta Access-Control-Max-Age, que especifica quanto tempo, em segundos, um cliente de navegador deve armazenar em cache resposta a uma solicitação de pré-renderização do CORS.

Alguns navegadores limitam isso a duas horas ou menos, mesmo se o valor máximo (86.400 s) é especificado.

 Access-Control-Max-Age: 7200
allowMethods

Define o cabeçalho de resposta Access-Control-Allow-Methods. que especifica quais métodos HTTP têm permissão para acessar recurso.

Por padrão, o Media CDN é compatível apenas com GET, métodos HEAD e OPTIONS. Em Visualização, para configurar a compatibilidade com outros métodos, consulte Métodos de rota.

 Access-Control-Allow-Methods: GET, OPTIONS, HEAD
allowHeaders

Define o cabeçalho Access-Control-Allow-Headers, que determina quais cabeçalhos podem ser enviados em uma solicitação CORS.

Isso geralmente é exigido por players de vídeo, que precisam acessar alguns cabeçalhos de resposta para conteúdo de vídeo ao solicitá-lo em origem cruzada.

 Access-Control-Allow-Headers: Content-Type, If-Modified-Since, Range, User-Agent
exposeHeaders

Define o cabeçalho de resposta Access-Control-Expose-Headers. que determina quais cabeçalhos podem ser acessados pelo servidor JavaScript.

Isso geralmente é exigido por players de vídeo, que talvez precisem acessar cabeçalhos de resposta específicos para conteúdo de vídeo ao solicitar conteúdo origem cruzada.

 Access-Control-Expose-Headers: Date, Cache-Status, Content-Type, Content-Length
allowCredentials

Define o cabeçalho de resposta Access-Control-Allow-Credentials. permitindo que o JavaScript do lado do cliente inspecione a resposta de solicitações com credenciais incluídas.

Esse cabeçalho é omitido quando definido como falso.

 Access-Control-Allow-Credentials: true
disabled Desativa o corsPolicy sem removê-lo. Antes de um voo Solicitações OPTIONS são encaminhadas 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 seguintes:

  • Um trajeto precisa ter um matchRule com exatamente um destes prefixMatch. fullPathMatch ou pathTemplateMatch definido. A API retornará um erro se não inclua um desses campos.
  • Verifique se o priority de cada trajeto está definido corretamente: mais específico rotas (mais longas) devem ter prioridade mais alta sobre rotas mais curtas e amplas correspondências de rota.
  • Por padrão, apenas as solicitações GET, HEAD e OPTIONS são aceitas. Em Pré-lançamento, para configurar o suporte a 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 HTTP 405 (Method Not Allowed).
  • As solicitações HTTP GET com corpo ou qualquer solicitação com trailers são rejeitadas com um erro HTTP 400, porque os corpos das solicitações não são permitidos em GET. solicitações.
  • O parâmetro de consulta e a correspondência de cabeçalho têm um "AND" lógico—a solicitação deve corresponder a todas as chaves de cabeçalho ou parâmetro de consulta (e valores, se especificados) para corresponder à rota especificada.

A seguir