Configure URL rewrites and redirections - CDN: Central de Documentação do Alibaba Cloud

Se o caminho de um recurso no servidor de origem mudar, o caminho correspondente no nó CDNDCDN também mudará. Quando um usuário solicita a URL original, o nó CDNDCDN reescreve a URL e redireciona a solicitação para o caminho de destino. Esse processo reduz as solicitações de busca na origem e melhora o desempenho de acesso do cliente.

Informações básicas

O código de status HTTP 302 (302 Found) indica que um recurso foi movido temporariamente. Após configurar uma regra de reescrita de URL, o nó CDNDCDN inclui a nova URL no cabeçalho HTTP Location. Ao receber a resposta 302, o cliente solicita a nova URL.

Por padrão, os nós CDNDCDN enviam um código de status 302 após a configuração de uma regra de reescrita de URL. Os códigos de status 303 e 307 também são suportados. Para alterar o código de status, envie uma solicitação ou abrindo um ticket.

Código	Significado	Método de tratamento	Cenário de aplicação típico
302	Found	O método GET não é alterado. Outros métodos podem mudar para GET.	A página está temporariamente indisponível por motivos imprevistos. Nesse caso, os mecanismos de busca não atualizam seus links.
303	See Other	O método GET não é alterado. Outros métodos mudam para GET. O corpo da mensagem é perdido.	Utilizado para redirecionamento de página após a conclusão de uma solicitação PUT ou POST. Isso evita que a operação seja acionada novamente se a página for atualizada.
307	Temporary Redirect	Nem o método nem o corpo da mensagem são alterados.	A página está temporariamente indisponível por motivos imprevistos. Nesse caso, os mecanismos de busca não atualizam seus links. Este código de status é preferível ao 302 quando o site suporta links ou operações para métodos diferentes de GET.

Importante

Um único nome de domínio pode ter até 50 regras de reescrita. Se houver várias regras configuradas, elas serão executadas sequencialmente de cima para baixo, conforme aparecem na lista de reescrita de URL no console CDNDCDN.

Diferenças entre Access URL Rewrite e Origin Path Rewrite

Recurso

Objeto afetado

Experiência do cliente

Cenário de aplicação

Rewrite access URLs

Afeta a URL acessada pelo cliente. Também altera a URL que o nó DCDN usa para buscas na origem.

Se a regra de execução for redirect, o cliente envia uma nova solicitação de acesso usando a URL redirecionada.
Se a regra de execução for break, a URL exibida ao cliente permanece igual à URL de acesso real. Não há alteração.

Comumente usado para migrar ou mapear URLs de um nome de domínio antigo para um novo. Também serve para fornecer URLs diferentes para clientes móveis e PCs.

Exemplo: Quando um cliente acessa old.example.com/hello, a URL de acesso é reescrita para new.example.com/hello.

Rewrite Origin Fetch Path

Afeta a URL que o nó DCDN usa para buscas na origem. A URL acessada pelo cliente não é alterada.

A URL exibida ao cliente permanece igual à URL de acesso real. Não há alteração.

Frequentemente utilizado para ocultar a estrutura real de URLs do servidor de origem e proteger suas informações. Também é aplicado no mapeamento de URLs para permitir que o nó DCDN busque conteúdo em pastas diferentes do servidor de origem.

Exemplo: Quando um cliente acessa cdn.example.com/hello, a URL de busca na origem é reescrita para origin.example.com/source/hello.

Diagrama de Access URL Rewrite

O cliente envia uma solicitação para um nó DCDN. A URL da solicitação é old.example.com/hello.
Ao receber a solicitação, o nó DCDN aplica a regra de reescrita de URL. O nó DCDN inclui a nova URL, new.example.com/hello, no cabeçalho Location da resposta 302 enviada ao cliente.
Após receber a resposta 302, o cliente envia uma solicitação para a nova URL.
O nó DCDN verifica seu cache. Se o cache contiver o conteúdo da URL reescrita, o nó retorna o conteúdo diretamente ao cliente. Caso contrário, o nó DCDN envia uma solicitação ao servidor de origem usando a URL reescrita, new.example.com/hello.
O servidor de origem recebe a solicitação e retorna o conteúdo da resposta ao nó DCDN.
O nó DCDN armazena o conteúdo da resposta em cache e o retorna ao cliente.

Diagrama de Origin Path Rewrite

O cliente envia uma solicitação para um nó DCDN. A URL da solicitação é cdn.example.com/files/hello.txt.
Ao receber a solicitação, o nó DCDN verifica seu cache. Se o cache contiver o conteúdo da URL solicitada, o nó retorna o conteúdo diretamente ao cliente. Caso contrário, o nó DCDN aplica a regra de reescrita de URL de busca na origem. Ele reescreve a URL de busca na origem para origin.example.com/secret/files/hello.txt e envia uma solicitação ao servidor de origem.
Após receber a solicitação, o servidor de origem retorna o conteúdo da resposta ao nó DCDN.
O nó DCDN armazena o conteúdo da resposta em cache e o retorna ao cliente.

Procedimento

Faça login no console CDN.
No painel de navegação à esquerda, clique em Domain Names.
Na página Domain Names, localize o nome de domínio desejado e clique em Manage na coluna Actions.
No painel de navegação do domínio, clique em Cache.
Clique na aba Access URL Rewrite.

Clique em Create e configure os parâmetros para reescrita de URLs de acesso.

Parâmetro	Descrição
Path to Be Rewritten	O caminho deve começar com `/`. Não pode incluir o cabeçalho de protocolo ou o nome de domínio. Expressões regulares PCRE são suportadas, como `^/hello$`. O conteúdo após um `#` em uma URL é um identificador de fragmento do lado do cliente. Os navegadores não enviam identificadores de fragmento ao servidor. Portanto, as regras de reescrita do DCDN não conseguem corresponder ao caminho após o `#`. Para configurar um redirecionamento para uma URL que contém um fragmento `#`, crie uma regra de reescrita separada para cada endereço de destino que corresponda exatamente ao caminho antes do `#`.
Target Path	Se a regra de execução estiver definida como Break, o caminho deve começar com `/`. Não pode incluir o cabeçalho de protocolo ou o nome de domínio. Se a regra de execução estiver definida como Redirect, o caminho pode incluir o cabeçalho de protocolo e o nome de domínio. Expressões regulares PCRE são suportadas. Por exemplo, use `$1` e `$2` para capturar strings entre parênteses do caminho a ser reescrito.
Flag	Redirect e Break são suportados por padrão. Redirect: Se uma URL de solicitação corresponder a uma regra, a solicitação será redirecionada para a URL de destino com um código de status 302. O cabeçalho Location que o nó CDN retorna ao cliente contém a URL de destino. Os parâmetros da URL original não são modificados. Após a execução desta regra, o sistema continua a corresponder às regras restantes. Break: Se uma URL de solicitação corresponder a uma regra, a solicitação será reescrita para a URL de destino. Os parâmetros da URL original não são modificados. Após a execução desta regra, o sistema não corresponde a nenhuma regra restante. As regras empty, enhance_break e enhance_redirect também são suportadas. Para usar essas regras, envie um ticket para que sejam configuradas em segundo plano. empty: Se várias regras forem configuradas e uma URL de solicitação corresponder a uma regra, o sistema continuará a corresponder às regras subsequentes após a execução da regra atual. enhance_break: Semelhante ao break, mas reescreve toda a URL, incluindo parâmetros. enhance_redirect: Semelhante ao redirect, mas reescreve toda a URL, incluindo parâmetros. Nota Diferentes regras de execução utilizam métodos de reescrita distintos. Elas também diferem quanto à possibilidade de a URL reescrita usar outros nomes de domínio ou protocolos: empty, Break e enhance_break reescrevem diretamente a URL de solicitação do usuário. Eles não suportam reescrita para outro nome de domínio ou protocolo, como de HTTP para HTTPS. Redirect e enhance_redirect usam um redirecionamento 302 para reescrever a URL. Eles suportam reescrita para outros nomes de domínio e protocolos: O endereço 302 Location pode ser definido como um nome de domínio diferente, não apenas o nome de domínio acelerado atual. Por exemplo, é possível reescrever uma URL do domínio `example.com` para o domínio `aliyundoc.com`. O endereço 302 Location suporta outros protocolos. Por exemplo, é possível reescrever uma URL de HTTP para HTTPS.
Rule Condition	Uma condição de regra identifica várias informações de parâmetros em uma solicitação de usuário. Isso determina se uma configuração entra em vigor para essa solicitação. Importante Ao referenciar condições de regra, a correspondência ocorre com base na prioridade das condições associadas, e não na ordem de configuração do próprio recurso. Do not use: Não utiliza uma condição de regra. Para adicionar ou editar condições de regra, gerencie-as em Rules Engine.
Nginx Var	Esta opção está desmarcada por padrão. Marque esta opção para usar variáveis NGINX integradas na URL de destino. Veja abaixo um exemplo de configuração: Caminho a ser reescrito: `^/test.jpg$` Caminho de destino: `/test.${arg_type}` Se você ativar o cálculo de variáveis NGINX, o valor de `${nginx_var}` será calculado. `${arg_type}` representa o valor do parâmetro `type` na URL original. Nota Para usar este parâmetro, envie um ticket para que ele seja configurado em segundo plano.

Clique em OK.

Após configurar o recurso de reescrita, você pode Modify ou Delete a regra na lista de reescrita.

Exemplos de configuração

Exemplo 1

Quando um cliente solicita http://example.aliyundoc.com/hello, o caminho da solicitação é /hello. O nó DCDN inclui a nova URL http://example.aliyundoc.com/index.html no cabeçalho Location da resposta 302 e retorna a resposta ao cliente. Em seguida, o cliente envia uma solicitação para http://example.aliyundoc.com/index.html.

Para esta regra, Path to Rewrite está definido como ^/hello$, Destination Path está definido como /index.html e Execution Rule está definido como redirect.

Nota

Durante um redirecionamento 302, se o cabeçalho Location não incluir um protocolo e nome de domínio, o cliente usará o protocolo e o nome de domínio da solicitação original por padrão.

Exemplo 2

Quando um cliente solicita http://example.aliyundoc.com/hello, o caminho da solicitação /hello corresponde à expressão regular ^/hello$. O nó DCDN retorna uma resposta 302 ao cliente. A resposta inclui a URL de destino https://test.aliyundoc.com/index.html no cabeçalho Location. Após receber a resposta, o cliente envia uma solicitação para https://test.aliyundoc.com/index.html.

Regra de configuração: Defina Path to Rewrite como ^/hello$, defina Destination Path como https://test.aliyundoc.com/index.html e defina Execution Rule como redirect.

Exemplo 3

Quando um cliente solicita http://www.example.com/cdn/url/http://image.example.com/image/cat.jpg, o caminho da solicitação contém /cdn/url/http://, que corresponde à expressão regular ^/cdn/url/http://(.*). O nó DCDN retorna uma resposta 302 ao cliente. A resposta inclui a URL de destino http://image.example.com/image/cat.jpg no cabeçalho Location. Após receber a resposta, o cliente envia uma solicitação para http://image.example.com/image/cat.jpg.

Para a regra de configuração, defina Destination Path como http://$1 e Execution Rule como redirect.

Exemplo 4

Quando um cliente solicita http://example.aliyundoc.com/stories/index.html#/voice/318, a parte #/voice/318 da URL é um identificador de fragmento do lado do cliente. O navegador não envia essa parte ao servidor. O caminho de solicitação real que o nó DCDN recebe é /stories/index.html. Portanto, ao configurar a regra de reescrita, defina Path to Rewrite como ^/stories/index\.html$ para corresponder ao caminho antes do #. Em seguida, defina Destination Path para a URL de destino e Execution Rule como Redirect.

Para redirecionar várias URLs de origem que possuem fragmentos # diferentes para URLs de destino distintas, configure uma regra de reescrita separada para cada caminho de origem. Isso ocorre porque um servidor não consegue distinguir URLs com base no conteúdo que segue o símbolo #.

Exemplo 5

Configurar uma página inicial de subdiretório: Retornar o arquivo de página inicial padrão de um subdiretório quando um cliente acessa o nome do subdiretório é um requisito comum para sites. Use a reescrita de URL de acesso para implementar essa capacidade no lado do DCDN sem modificar seu servidor de origem. Por exemplo, se o arquivo da página inicial for https://www.example.com/cdn/index.html, após a configuração entrar em vigor, uma solicitação do cliente para https://www.example.com/cdn ou https://www.example.com/cdn/ retornará o arquivo da página inicial.

Antes de configurar as regras, certifique-se de que o arquivo da página inicial no subdiretório do servidor de origem esteja acessível. Por exemplo, garanta que https://www.example.com/cdn/index.html possa ser retornado conforme esperado.

O caminho da solicitação de um cliente pode ou não terminar com uma barra final (/). Portanto, configure as duas regras a seguir para corresponder a ambos os casos:

Regra 1: Defina Path to Rewrite como ^/(.+)/$, defina Destination Path como /$1/index.html e defina Execution Rule como Break.
Regra 2: Defina Path to Rewrite como ^/([^.?#]+)$, defina Destination Path como /$1/index.html e defina Execution Rule como Break.

Após a configuração entrar em vigor, acesse diretamente um subdiretório, como https://www.example.com/cdn. Se o arquivo da página inicial do subdiretório for retornado conforme esperado, a configuração foi bem-sucedida.