Rules Engine para Edge Application

O Rules Engine é uma funcionalidade do Edge Application controla a execução de comportamentos através de operadores lógicos. Através do Rules Engine, você pode construir uma arquitetura que proporciona melhor performance para seus usuários consumindo menos recursos e processando na origem.

Cada requisição de uma aplicação criada com o Azion Real-Time Manager (RTM) é processada numa sequência fixa de duas fases:

  1. Request Phase: ocorre quando um usuário submete uma requisição à edge application.
  2. Response Phase: ocorre quando um usuário recebe uma resposta da edge application.

Em cada fase de processamento, você pode definir um conjunto de regras para tratar a requisição de acordo com as necessidades da sua aplicação ou negócio. Uma vez selecionada a fase em que a sua regra será executada, você pode criar uma nova regra.

As regras são concebidas para seguir uma lógica condicional se-então. Cada regra é composta de Criteria (se), que são os critérios que definirão o conjunto de condições que devem ser cumpridas para a execução de Behaviors (então), ou comportamentos.

Para desencadear os comportamentos desejados para sua aplicação, você pode utilizar variáveis, operadores de comparação e operadores lógicos. Se as condições forem cumpridas, os comportamentos de cada regra são executados em sequência até que todas as regras sejam processadas.

EscopoRecurso
Primeiros passos de Edge ApplicationPrimeiros passos
Criar uma regraComo criar regras de Request e Response usando o Rules Engine para Edge Application
Criar uma configuração de cacheComo configurar políticas de cache para Edge Application
Mitigar HTTPoxy usando rulesComo mitigar a vulnerabilidade HTTPoxy

Ao criar uma regra, você será solicitado a selecionar uma das duas fases de processamento disponíveis: Request Phase ou Response Phase.

Durante a Request Phase, o edge node processa as requisições do usuário final. Para as regras da Request Phase, todas as variáveis associadas aos dados fornecidos pelo usuário na requisição podem ser utilizadas. No entanto, as variáveis relacionadas ao conteúdo que será entregue ao usuário nessa fase não são acessíveis, pois a resposta ainda não foi processada pela aplicação.

Além disso, é na Request Phase que você determina como a aplicação armazenará o conteúdo em cache. Se sua aplicação não permitir nenhuma forma de armazenamento em cache, você tem a opção de definir as condições sob as quais o armazenamento em cache deve ser desconsiderado.

Na Response Phase, sua aplicação trata do conteúdo que será entregue a seus usuários. Todo o processamento feito nessa fase é dinâmico e a entrega de cada usuário é realizada de forma independente com base em seus requisitos específicos.


Além do nome da regra, você pode adicionar uma descrição para ela usando o campo Description. Sua descrição ficará visível na lista de regras e pode ser usada para identificar o que a regra faz.


A seção Criteria do Rules Engine é onde você define os critérios para a execução da regra. Critérios são compostos de:

  • variáveis
  • operadores de comparação
  • argumentos, quando aplicável

A inclusão de argumentos em um critério depende dos operadores de comparação escolhidos, e seus formatos estão descritos nas seções variáveis e operadores de comparação. Operadores lógicos servem para incrementar a quantidade de comparações que a regra irá executar.

Por exemplo, o seguinte critério identifica se um usuário está usando um navegador web desktop para acessar sua aplicação através de uma expressão regular como argumento:

VariávelOperador de comparaçãoArgumento
If${http_user_agent}matches(Chrome|Mozilla)

Confira a lista completa de variáveis disponíveis e sua fase de processamento:

VariávelDescriçãoDisponível para
${arg_name}Argumento name enviado pelo usuário na linha de requisição (query string). Por exemplo, para a requisição GET /path?Search=test, a variável ${arg_search} assumirá o valor test.Request Phase
Response Phase
${args}Todos os argumentos enviados pelo usuário na linha de requisição (query string). Por exemplo: para a requisição GET /path?Search=test, a variável assumirá o valor Search=test.Request Phase
Response Phase
${cookie_name}Valor do cookie name. Por exemplo, para o cookie_icl_current_language=pt-br, a variável ${cookie_icl_current_language} assumirá o valor pt-br.Request Phase
Response Phase
${device_group}Nome do device group. Você pode criar device groups na aba Device Groups de sua aplicação no Real-Time Manager.Request Phase
Response Phase
${domain}Similar à variável ${host}. Armazena o host name ou o cabeçalho Host da requisição, removendo o último subdomínio após o domínio de segundo nível. Por exemplo: para um domínio az.blog.dominio.com, essa variável irá carregar o valor blog.dominio.com.Request Phase
Response Phase
${geoip_city}Nome da cidade por extenso, utilizando a base de geolocalização geoip_city. Por exemplo: Sao Paulo, London.Request Phase
Response Phase
${geoip_city_continent_code}Código de continente com 2 letras, utilizando a base de geolocalização geoip_city. Por exemplo: EU para Europa, NA para América do Norte.Request Phase
Response Phase
${geoip_city_country_code}Código de país com 2 letras, utilizando a base de geolocalização geoip_city. Por exemplo: RU para Rússia, BR para Brasil.Request Phase
Response Phase
${geoip_city_country_name}Nome do país por extenso, utilizando a base de geolocalização geoip_city. Por exemplo: United States, Brazil.Request Phase
Response Phase
${geoip_continent_code}Código de continente com 2 letras. Por exemplo: EU para Europa, NA para América do Norte.Request Phase
Response Phase
${geoip_country_code}Código de país com 2 letras, utilizando a base de geolocalização geoip_country. Por exemplo: RU para Rússia, BR para Brasil.Request Phase
Response Phase
${geoip_country_name}Nome do país por extenso, utilizando a base de geolocalização geoip_country. Por exemplo: United States, Brazil.Request Phase
Response Phase
${geoip_region}Código da região com 2 letras. Por exemplo: RS para Rio Grande do Sul, ON para Toronto etc.Request Phase
Response Phase
${geoip_region_name}Nome do país por extenso, utilizando a base de geolocalização geoip_region. Por exemplo: Ontario, Sao Paulo etc.Request Phase
Response Phase
${host}Em ordem de precedência: o host name da linha de requisição, ou o valor do campo de cabeçalho Host da requisição, ou o nome do servidor atendendo a requisição. Por exemplo: blog.domain.com.Request Phase
Response Phase
${http_name}O valor do campo de cabeçalho da requisição. name deve ser um cabeçalho HTTP válido convertido em letras minúsculas; hífens devem ser convertidos para underscore. Por exemplo: ${http_accept} assumirá o valor da campo de cabeçalho Accept da requisição HTTP.Request Phase
Response Phase
${remote_addr}O endereço IP do cliente que está realizando a requisição HTTP.Request Phase
Response Phase
${remote_port}A porta HTTP sendo usada na URL da requisição do cliente.Request Phase
Response Phase
${remote_user}O username fornecido pela autenticação básica, quando houver.Request Phase
Response Phase
${request}A primeira linha da requisição original do request feito pelo cliente. É composta pelo método da requisição, a URI da requisição e a versão HTTP. Por exemplo: GET /path HTTP/2.0.Request Phase
Response Phase
${request_method}O método HTTP da requisição. Por exemplo: GET.Request Phase
Response Phase
${request_uri}A URI completa da requisição, com argumentos (query string). Caracteres UTF-8 especiais são codificados em URL encoding. Por exemplo: /path?var=value%20of%20var.Request Phase
Response Phase
${scheme}O scheme da requisição: http ou https.Request Phase
Response Phase
${sent_http_name}O valor do campo de cabeçalho de resposta name. O argumento name deve ser convertido para letras minúsculas e os hífens devem ser convertidos para underscore. Por exemplo: para um cabeçalho Content-Length: 9593, a variável ${sent_http_content_length} assumirá o valor 9593.Response Phase
${server_addr}O endereço IP do servidor que irá receber a requisição HTTP. Por exemplo: 200.0.0.0.Request Phase
${server_port}A porta HTTP do servidor que irá receber a requisição. Por exemplo: 8080.Request Phase
${status}O status code da resposta. Por exemplo: 200.Response Phase
${tcpinfo_rtt}Round-Trip Time (RTT) da conexão TCP do cliente, em microsegundos. Por exemplo: 24763.Response Phase
${upstream_addr}O endereço IP e porta da origem consultada para obtenção da resposta. Caso múltiplas origens sejam consultadas durante o processamento da requisição, os endereços serão separados por vírgula (,). Por exemplo: 192.168.1.1:80, 192.168.1.2:80. Se um redirect interno de um grupo de servidores para outro ocorrer, iniciado por um X-Accel-Redirect ou por uma página de erro, os endereços dos diferentes grupos serão separados por dois pontos (:). Por exemplo: 192.168.1.1:80, 192.168.1.2:80 : 192.168.10.1:80, 192.168.10.2:80.Response Phase
${upstream_cookie_name}Valor do cookie name enviado pela origem através do campo de cabeçalho Set-Cookie. Caso múltiplas origens sejam consultadas durante o processamento da requisição, apenas os cookies da última origem são armazenados.Response Phase
${upstream_http_name}Valor do campo de cabeçalho name enviado pela origem. O argumento name deve ser convertido para letras minúsculas e os hífens devem ser convertidos para underscore. Caso múltiplas origens sejam consultadas durante o processamento da requisição, apenas os cabeçalhos da última origem são armazenados. Por exemplo: ${upstream_http_server} assumirá o valor do campo de cabeçalho Server enviado pela última origem consultada.Response Phase
${upstream_status}Status Code da resposta da origem enviada para o RTM. Caso múltiplas origens sejam consultadas durante o processamento da requisição, os status codes serão separados por vírgula (,). Se um redirect interno de um grupo de servidores para outro ocorrer, iniciado por um X-Accel-Redirect ou por uma página de erro, os status codes dos diferentes grupos serão separados por dois pontos (:).Response Phase
${uri}A URI normalizada (urldecoded) da requisição. Por exemplo: /path/my file.txt.

O valor da ${uri} pode mudar durante o processamento de uma requisição, por exemplo, quando ocorre um redirect interno ou quando são utilizados arquivos index. NÃO carrega os parâmetros do Query String como ${request_uri} faz.
Request Phase
Response Phase

Variáveis para Mutual Transport Layer Security (mTLS)

Seção intitulada Variaveis para Mutual Transport Layer Security (mTLS)

Utilize essas variáveis no Rules Engine da sua edge application para configurar Mutual Transport Layer Security (mTLS).

VariávelDescriçãoFase
${ssl_client_fingerprint}Retorna o Secure Hash Algorithm 1 (SHA-1) do client certificate.Requisição
${ssl_client_escaped_cert}Retorna o client certificate no formato Private Enhanced Mail (PEM) .pem, como uma URL encoced string.Requisição
${ssl_client_s_dn}Retorna o “subject DN” do client certificate.Requisição
${ssl_client_s_dn_parsed}Retorna o “subject CN” (extraído do “subject DN”) do client certificate.Requisição
${ssl_client_cert}Retorna o client certificate no formato PEM. Esta é uma variável descontinuada. Use $ssl_client_escaped_cert.Requisição
${ssl_client_i_dn}Retorna o “issuer DN” do client certificate.Requisição
${ssl_client_serial}Retorna o serial number do client certificate.Requisição
${ssl_client_v_end}Retorna a data de expiração do client certificate.Requisição
${ssl_client_v_remain}Retorna o tempo, em dias, que falta para o client certificate expirar.Requisição
${ssl_client_v_start}Retorna a data de emissão do client certificate.Requisição
${ssl_client_verify}Retorna o resultado da verificação do client certificate. Pode ser SUCESS, FAILED:reason ou NONE.Requisição

A maioria dos serviços mTLS depende do recebimento do certificado do usuário. Usando o Real-Time Manager (RTM), você pode enviar a variável ${ssl_client_escaped_cert} no Request Header XFCC (X-Forward-Client-Cert) para a origem e, em seguida, configurar sua edge application para usar esse header com os dados do certificado. :::

Saiba mais sobre support for mTLS

Para Behaviors que requerem um argumento, você pode utilizar as mesmas variáveis que estão disponíveis na fase de processamento. Dessa forma você pode, por exemplo, compor cookies ou cabeçalhos HTTP utilizando dados coletados durante a fase de requisição, tais como o device group a qual o usuário pertence ou sua geolocalização.

Por exemplo, para a regra na Response Phase:

If ${host} is equal myhost.com Then Add Response Cookie cookie-host-value=${host}

Quando ativada a regra, se a requisição for feita do Host determinado no critério, a resposta retornará o cabeçalho com o seguinte valor: Set-Cookie: cookie-host-value=myhost.com.

A Azion também disponibiliza variáveis especiais que agem como funções e levam argumentos. As seguintes variáveis podem ser usadas para compor argumentos de Behavior:

VariávelDescrição
${cookie_time_offset(number)}Retorna a data atual acrescida de um offset em segundos, informado como argumento, para ser utilizado na definição do tempo de expiração de um cookie. Por exemplo, se você deseja que o cookie expire em 1 hora a partir do momento que foi criado, utilize o behavior Add Response Cookie com o argumento: cookie-name=cookie-value; Expires=${cookie_time_offset(3600)}
${encode_base64(string)}Retorna o argumento codificado em base64. Por exemplo, ${encode_base64 (www.domain.com)} retornará o valor d3d3LmRvbWFpbi5jb20K

OperadorDescriçãoTipo de argumento
is equalO valor da variável é igual ao argumento, comparado caractere a caractere.string
is not equalO valor da variável não é exatamente igual ao argumento.string
starts withO valor da variável inicia pelo argumento.string
does not start withO valor da variável não inicia pelo argumento.string
matchesO valor da variável coincide com a expressão regular informada como argumento.regular expression
does not matchO valor da variável não coincide com a expressão regular informada como argumento.regular expression
existsA variável tem valor definido. Por exemplo: ${arg_search} existe se foi enviado um argumento search na query string da requisição.-
does not existA variável não tem valor definido. Por exemplo: ${arg_search} não existe se não foi enviado um argumento search na query string da requisição.-

Múltiplos critérios podem ser adicionados por meio dos operadores lógicos AND e OR. Com isso, cada regra pode conter até 10 critérios.

O operador AND tem precedência implícita sobre o operador OR. Se for necessária precedência explícita, você pode adicionar múltiplos grupos de critérios apenas sob a lógica AND.


Na seção de Behaviors da Rules Engine, você adiciona os comportamentos que deseja executar, caso as condições da regra sejam atendidas.

Por exemplo, esse comportamento redireciona o usuário para uma versão em inglês de um path de FAQ:

ComportamentoArgumento
Redirect To (302 Found)/en-us/faq

Cada regra pode carregar até 10 comportamentos.

Em cada fase de processamento, comportamentos distintos estão disponíveis.

Request Phase Response Phase Requer Application Acceleration

Adiciona um cookie no cabeçalho Set-Cookie da requisição ou da resposta. O valor do cookie deve ser informado como argumento no formato cookie-name=cookie-value.

Para cookies de resposta, você pode adicionar as seguintes políticas de Set-Cookie ao argumento, separadas do valor do cookie por ponto e vírgula (;):

  • Expires=date (EEE, d MMM yyyy HH:mm
    Z)
  • Domain=domain-value
  • Path=path-value
  • Max-age=number (TTL in seconds, takes precedence over Expires)
  • SameSite=value; Secure
  • HttpOnly

Múltiplas políticas também são permitidas se separadas por ponto e vírgula (;). Por exemplo: cookie-name=cookie-value; Domain=domain-value; Path=path-value; SameSite=value.

Você também pode usar variáveis no lugar de valores. Por exemplo: Path=${uri}; Domain=${host}.

Request Phase Response Phase

Adiciona um campo de cabeçalho na requisição que será enviada a origem ou na resposta que será enviada para o usuário. O campo de cabeçalho deve ser informado como argumento no formato Field: value.

Request Phase Requer Application Acceleration

Define que a Azion não deverá armazenar em cache a resposta de sua origem. A execução desta regra não tem impacto sobre o cache no browser dos usuários, o qual deve ser definido utilizando o behavior Set Cache Policy.

Através do Bypass Cache, você configura o serviço da Azion para repassar todas as requisições a um path diretamente para sua origem. Contudo, você contará com importantes otimizações de protocolo para acelerar sua aplicação e conexão keep-alive entre os edge nodes da Azion e sua origem sempre que possível.

Consulte o guia Como configurar a políticas de cache para Edge Application para mais informações sobre o uso de Bypass Cache.

Diferença entre Bypass Cache e TTL 0

Seção intitulada Diferenca entre Bypass Cache e TTL 0

Tanto o comportamento Bypass Cache quanto o Maximum TTL em zero segundos permitem otimizar a entrega de conteúdo e reduzir os tempos de carregamento na origem, mas seus efeitos são levemente diferentes.

Ao usar o comportamento Bypass Cache, todas as solicitações HTTP e HTTPS recebidas pelos edge nodes da Azion serão enviadas para a origem, sem armazenar nenhum conteúdo em cache. Utilize o Bypass Cache se você quiser fornecer conteúdo diferente para cada solicitação de usuário.

No entanto, ao definir o TTL em 0 (zero) segundos, várias solicitações em paralelo aos edge nodes da Azion serão enviadas como uma única solicitação à origem. Nesse caso, os edge nodes da Azion também validam as alterações no conteúdo com sua origem usando o parâmetro If-Modified-Since. Se o objeto não tiver sido alterado desde a última solicitação, o conteúdo não precisará ser transferido novamente, o que pode resultar em uma resposta 304 Not Modified muito mais rápida. Além disso, o TTL máximo de cache em 0 ainda irá gerar um objeto de cache que vive por 999 milissegundos.

Request Phase Requer Application Acceleration

Comportamento de apoio para manipulação de strings. Armazena em uma variável temporária o resultado da captura de grupos de correspondência definidos por uma regex aplicada a um dos campos da requisição HTTP disponibilizados. Essa variável temporária pode ser posteriormente referenciada no behavior Rewrite Request para montar a string de reescrita.

Este behavior requer três argumentos:

  • captured array name: o nome que você deseja dar à variável temporária onde será armazenado o array de strings capturadas.
  • subject: o campo da requisição HTTP de onde você deseja capturar alguma string.
  • regex: a expressão regular usada para capturar as strings. Cada grupo capturado deve ser representado entre parênteses.

Por exemplo, para capturar o caminho e o nome de um arquivo em uma requisição HTTP, você pode utilizar:

  • captured array name: capture
  • subject: ${uri}
  • regex: ^(./)([^/])$

É possível referenciar a variável de captura como um array utilizando a notação %{*variable[index]*}. Por se tratar de uma variável local, você só poderá utilizá-la dentro da mesma regra que estiver configurando. Neste exemplo, se a URI for /path/image.jpg, a variável de captura apresentará os seguintes valores:

  • %{capture[0]} = "/path/image.jpg"
  • %{capture[1]} = "/path/"
  • %{capture[2]} = "image.jpg"

Você também pode nomear os índices para referenciá-los usando nomes em vez de um índice numérico. Para tanto, utilize a notação ?<name>, como no exemplo:

  • captured array name: capture
  • subject: ${uri}
  • regex: ^(?<path>.*/)(?<filename>[^/]*)$
Request Phase Response Phase

Encerra o processamento da requisição e entrega o conteúdo para o usuário, sem executar nenhuma das regras seguintes. Ao utilizar o behavior Deliver, você estará forçando o término do processamento imediatamente.

Request Phase

Entrega um 403 Forbidden para o usuário. Por se tratar de uma regra finalizadora, esse behavior encerra o processamento da requisição.

Request Phase Response Phase

Ativa a compressão de dados em gzip, caso suportada pelo browser do usuário. Consulte o guia de Como habilitar compressão gzip para mais informações.

Request Phase Requer Edge Caching

Ativa segmentação de objetos grandes em slices de 1MB, caso sua origem tenha suporte a HTTP range requests. Utilize este behavior se você entrega mídias com mais de 1MB através da Azion para que a entrega do conteúdo para seus usuários seja iniciada da edge, mesmo antes de ter recebido todo o objeto de sua origem.

Ao ativar esta funcionalidade, a Azion irá requisitar os objetos para sua origem via range requests e os mesmos serão cacheados na Azion com Advanced Cache Key.

Caso sua origem não tenha suporte a range requests, a Azion só poderá iniciar a entrega de seu conteúdo para seus usuários após sua origem finalizar o envio completo do objeto.

Request Phase Requer Live Ingest

Este behavior é incluído automaticamente pela Azion toda vez que você selecionar uma origem do tipo Live Ingest. Duas ações são executadas nessa situação: o bypass de todas suas regras da Cache Phase e a imposição da política de cache definida pela Azion para transmissões live em HLS.

A política de cache da Azion para transmissões live em HLS é de 5 segundos de cache para playlists (.m3u8) e 60 segundos de cache para chunks (.ts).

Request Phase Response Phase Requer Application Acceleration

Remove um cookie do cabeçalho da requisição que será enviada para a origem ou da requisição que será enviada para o usuário. Como argumento, você pode informar o nome do cookie que deseja remover no formato cookie-name.

Para remover apenas valores específicos, você deve informar o nome e valor do cookie no formato cookie-name=cookie-value.

Request Phase Response Phase

Remove um campo do cabeçalho da requisição que será enviada para a origem ou da resposta que será enviada para o usuário. O nome do cabeçalho deve ser informado como argumento, por exemplo: Header-Name.

Request Phase

Finaliza a fase de requisição. Qualquer comportamento ou regra abaixo desse comportamento não será executada.

Request Phase Requer Application Acceleration

Ao utilizar o comportamento Forward Cookies, você está determinando que a Azion encaminhe aos seus usuários o cabeçalho Set-Cookie recebido da origem, mesmo quando for identificado conteúdo em cache (HIT).

Para evitar que um usuário receba o cabeçalho Set-Cookie da sessão de outro usuário, consulte o guia sobre políticas de cache.

Uma alternativa ao envio do cabeçalho de resposta Set-Cookie é a criação de cookies por JavaScript, que permite criar, ler e expirar cookies através da propriedade document.cookie.

O JavaScript cookie deve possuir o seguinte formato:

document.cookie = "username=John Doe; expires=Thu, 18 Dec 2013 12:00:00 UTC; path=/";

Por padrão, a Azion não irá filtrar o Request Header Cookie, independentemente de sua configuração de Forward Cookies. Sendo assim, JavaScript Cookies poderão ser enviados para sua origem para viabilizar o gerenciamento de sua aplicação.

Request Phase

Retorna um código 204 quando se faz um request à aplicação ao invés do código recebido da origem.

Request Phase Requer Image Processor

Ativa a otimização de imagens.

Request Phase Requer aplicação HTTPS

Redireciona a requisição HTTP para a respectiva URL em HTTPS. Caso a requisição já seja HTTPS, não executa nenhum comportamento.

Request Phase Response Phase

Redirect to (301 Moved Permanently) e Redirect To (302 Found) redirecionam o usuário para uma outra URL informada como argumento, retornando o status code 301 Moved Permanently ou 302 Found.

É recomendado que estes comportamentos sejam utilizados para mudanças de caminhos: 301 Moved Permanently para mudanças permanentes e 302 Found para mudanças mudanças temporárias.

Por se tratarem de regras finalizadoras, esses behaviors encerram o processamento da requisição.

Request Phase Requer Application Acceleration

Modifica o path do recurso que será requisitado para a origem. Você pode reescrever o path do recurso utilizando:

  • Uma string.
  • As variáveis da requisição (as mesmas que podem ser utilizadas em Criteria).
  • As variáveis locais, no formato %{name[index]}, com o resultado de captura de strings, ao utilizar o behavior Capture Match Groups.

Por exemplo, se você deseja que a requisição de um usuário para o recurso /original/image.jpg seja enviada para sua origem como /new/image.jpg, você pode:

  1. Utilizar o behavior Capture Match Groups com os argumentos:
  • captured array name: capture
  • subject: ${uri}
  • regex: /original/(.*)
  1. Utilizar o behavior Rewrite Request com o argumento /new/%{capture[1]}

Request Phase Response Phase Requer Application Acceleration Requer Edge Functions

Executa uma função criada no Edge Functions e instanciada pela aba Edge Functions da edge application. Consulte o guia de Como executar funções serverless para mais informações.

Request Phase

Atribui a política de cache que deve ser utilizada para a requisição. As políticas de cache devem ser previamente configuradas na Cache Settings.

Na política de cache você configura o tempo que o objeto deve ser armazenado em cache e as regras para variação dos objetos em cache com a Advanced Cache Key.

Request Phase

Atribui a origem que deve ser consultada pelo edge node para a requisição.

As origens devem ser previamente configuradas usando Origins.


Você pode executar o fazer o debug de regras criadas com Rules Engine usando GraphQL API, Data Streaming ou Real-Time Events.


Contribuidores