# Rules Engine para Applications import DocButton from '~/components/webkit/DocButton.vue'; import Tag from '~/components/webkit/Tag.vue'; import TableContainer from '~/components/Table/TableContainer.astro'; import RulesExecution from '~/includes/snippets/RulesEngineExecution/pt/snippet.mdx'; O **Rules Engine** é uma funcionalidade do **Applications** 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 Console](https://console.azion.com/) é processada numa sequência fixa de duas fases: 1. **Request Phase**: ocorre quando um usuário submete uma requisição à application. 2. **Response Phase**: ocorre quando um usuário recebe uma resposta da 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. :::caution Antes de criar uma regra, você deve ativar o módulo [Application Accelerator](/pt-br/documentacao/produtos/build/applications/application-accelerator/), que expande a usabilidade do **Rules Engine**, pois habilita funcionalidades de computação serverless à **Applications**. Caso o módulo não seja ativado, somente algumas variáveis e comportamentos estarão disponíveis para o Rules Engine. ::: ## Implementação | Escopo | Recurso | | --- | --- | | Primeiros passos de Applications | [Primeiros passos](/pt-br/documentacao/produtos/build/applications/primeiros-passos/) | | Criar uma regra | [Como criar regras de Request e Response usando o Rules Engine para Applications](/pt-br/documentacao/produtos/guias/rules-engine/) | | Criar uma configuração de cache | [Como configurar políticas de cache para Applications](/pt-br/documentacao/produtos/guias/cache-settings/) | | Mitigar HTTPoxy usando rules | [Como mitigar a vulnerabilidade HTTPoxy](/pt-br/documentacao/produtos/guias/como-mitigar-vulnerabilidade-httpoxy/) | --- ## Fases de processamento Ao criar uma regra, você será solicitado a selecionar uma das duas fases de processamento disponíveis: **Request Phase** ou **Response Phase**. ### Request 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. ### Response Phase 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. --- ## Nome Cada regra deve ter um nome único e fácil de lembrar, permitindo que você a referencie e gerencie facilmente dentro do seu sistema. --- ## Descrição 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. --- ## Criteria 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 - Operadores lógicos - 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](#variaveis) e [operadores de comparação](#operadores-de-comparacao). [Operadores lógicos](#operadores-logicos) 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ável | Operador de comparação | Argumento | | --- | ---- | --- | --- | | If | `${http_user_agent}` | *matches* | `(Chrome\|Mozilla)` | ### Variáveis Confira a lista completa de variáveis disponíveis e sua fase de processamento: | Variável | Descrição | Exemplo | Fase | | --- | --- | --- | --- | | `${arg_name}` | Valor do nome do parâmetro na string de consulta da URL | `${arg_search}` assume `test` para `/path?search=test` | Request
Response | | `${args}` | Todos os nomes de parâmetros e valores enviados na string de consulta da URL | `${args}` assume `search=test` para `/path?search=test` | Request
Response | | `${cookie_name}` | Valor do cookie name | `${cookie_icl_current_language}` assume `pt-br` para `icl_current_language = pt-br` | Request
Response | | `${device_group}` | Nome do device group. Você pode criar [device groups](/pt-br/documentacao/produtos/build/applications/device-groups/) na aba **Device Groups** de sua aplicação no Azion Console | `Mobile` | Request
Response | | `${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 | `${domain}` assume `blog.dominio.com` para `az.blog.dominio.com` | Request
Response | | `${geoip_city}` | Nome da cidade por extenso, utilizando a base de geolocalização `geoip_city` | `Sao Paulo` | Request
Response | | `${geoip_city_continent_code}` | Código de continente com 2 letras, utilizando a base de geolocalização `geoip_city` | `EU` para Europa | Request
Response | | `${geoip_city_country_code}` | Código de país com 2 letras, utilizando a base de geolocalização `geoip_city` | `BR` para Brasil | Request
Response | | `${geoip_city_country_name}` | Nome do país por extenso, utilizando a base de geolocalização | `United States` | Request
Response | | `${geoip_continent_code}` | Código de continente com 2 letras | `NA` para América do Norte | Request
Response | | `${geoip_country_code}` | Código de país com 2 letras, utilizando a base de geolocalização `geoip_country` | `RU` para Rússia | Request
Response | | `${geoip_country_name}` | Nome do país por extenso, utilizando a base de geolocalização `geoip_country` | `Brazil` | Request
Response | | `${geoip_region}` | Código da região com 2 letras | `RS` para Rio Grande do Sul | Request
Response | | `${geoip_region_name}` | Nome da região por extenso, utilizando a base de geolocalização `geoip_region` | `Ontario` | Request
Response | | `${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 | `blog.domain.com` | Request
Response | | `${http_name}` | O valor do campo de cabeçalho da requisição. `name` deve ser um [cabeçalho HTTP](https://developer.mozilla.org/en-US/docs/Glossary/Request_header) válido convertido em letras minúsculas; hífens devem ser convertidos para underscore | `${http_accept}` assume `image/webp,image/apng` para `Accept: image/webp,image/apng` | Request
Response | | `${remote_addr}` | O endereço IP do cliente que está realizando a requisição HTTP | `200.10.2.50` | Request
Response | | `${remote_port}` | A porta HTTP sendo usada na URL da requisição do cliente | `443` | Request
Response | | `${remote_user}` | O username fornecido pela autenticação básica, quando houver | `username` | Request
Response | | `${request}` | A primeira linha da requisição original do request feito pelo cliente. É composta pelo método da requisição, o URI da requisição e a versão HTTP | `GET /path HTTP/2.0` | Request
Response | | `${request_body}` | O conteúdo do corpo da requisição HTTP. | `{"name": "azion", "action": "login"}` | Request
Response | | `${request_method}` | O método HTTP da requisição | `GET` | Request
Response | | `${request_uri}` | O URI completo da requisição, com argumentos (query string). Caracteres UTF-8 especiais são codificados em URL encoding | `/path?var=value%20of%20var` | Request
Response | | `${scheme}` | O scheme da requisição | `https` | Request
Response | | `${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 (`_`) | `${sent_http_content_length}` assume `9593` para `Content-Length: 9593` | Response | | `${server_addr}` | O endereço IP do servidor que recebe a requisição HTTP | `200.0.0.0` | Request | | `${server_port}` | A porta HTTP do servidor que irá receber a requisição | `8080` | Request | | `${status}` | O status code da resposta | `200` | Response | | `${tcpinfo_rtt}` | Round-Trip Time (RTT) da conexão TCP do cliente, em microsegundos | `24763` | Response | | `${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 (`,`). 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 (`:`) | `192.168.1.1:80, 192.168.1.2:80`
`192.168.1.1:80, 192.168.1.2:80 : 192.168.10.1:80, 192.168.10.2:80` | Response | | `${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 | `${upstream_cookie_uuid}` assume `12345` para `Set-Cookie: uuid = 12345` | Response | | `${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 | `${upstream_http_server}` assume `UploadServer` para `Server: UploadServer` | Response | | `${upstream_status}` | Status Code da resposta da origem enviada para o Azion Console. 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 (`:`) | `200, 201`
`500, 502 : 200, 200` | Response | | `${uri}` | O URI normalizado (*URL decoded*) da solicitação.

O valor de `${uri}` pode mudar durante o processamento de uma solicitação, por exemplo, quando ocorre um redirecionamento interno ou quando arquivos de índice são usados. Para parâmetros de query string e caracteres *URL encoded*, use `${request_uri}` | `/path/my file.txt` | Request
Response | ### Variáveis para Mutual Transport Layer Security (mTLS) Utilize essas variáveis no **Rules Engine** da sua application para configurar **Mutual Transport Layer Security (mTLS)**. Variáveis para mTLS estão disponíveis apenas para a **Request Phase**. | Variável | Descrição | Exemplo | | --- | --- | --- | | `${ssl_client_fingerprint}` | O *Secure Hash Algorithm 1 (SHA-1)* do *client certificate* | `2fd4e1c67a2d28fced849` | | `${ssl_client_escaped_cert}` | O *client certificate* no formato *Private Enhanced Mail (PEM)*, formatado como uma string *URL encoded* | `-----BEGIN%20CERTIFICATE-----%0AMIICnz...%0A-----END%20CERTIFICATE-----` | | `${ssl_client_s_dn}` | Retorna o `subject DN` do *client certificate* como string | `/C=US/ST=California/L=San Francisco/O=Example CA/CN=example.com` | | `${ssl_client_s_dn_parsed}` | Retorna o `subject CN` (extraído do `subject DN`) do *client certificate* como string | `example.com` | | `${ssl_client_cert}` | **Esta é uma variável descontinuada**. Use `${ssl_client_escaped_cert}`

Retorna o *client certificate* no formato PEM | `-----BEGIN CERTIFICATE-----`
`MIICnz...`
`-----END CERTIFICATE-----` | | `${ssl_client_i_dn}` | Retorna o `issuer DN` do *client certificate* como string | `/C=US/ST=California/L=San Francisco/O=Example CA/CN=issuer.com` | | `${ssl_client_serial}` | Retorna o número de série do *client certificate* | `6C:0A:83:7E:92:3B:D6:C6:E3:56:50:E7` | | `${ssl_client_v_end}` | Retorna a data de expiração do *client certificate* em formato YYYYMMDDHHmmSS | `20230115120000` | | `${ssl_client_v_remain}` | Retorna o tempo, em dias, que falta para o *client certificate* expirar | `100` | | `${ssl_client_v_start}` | Retorna a data de emissão do *client certificate* em formato YYYYMMDDHHmmSS | `20230115120000` | | `${ssl_client_verify}` | Retorna o resultado da verificação do *client certificate* | `SUCCESS`
`FAILED:reason`
`NONE` | ::tip A maioria dos serviços mTLS depende do recebimento do certificado do usuário. Usando o [Azion Console](https://console.azion.com), você pode enviar a variável `${ssl_client_escaped_cert}` no cabeçalho `X-Forward-Client-Cert` (XFCC) na requisição para a origem e, em seguida, configurar sua application para usar esse header com os dados do certificado. ::: ### Variáveis como argumentos 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 de requisição utilizando dados coletados durante a **Request Phase**, tais como o device group a qual o usuário pertence ou sua geolocalização. Por exemplo, para a regra na **Response Phase**: | | Variável | Operador de comparação | Argumento | | - | - | - | - | | If | `${host}` | *is equal* | `host.com` | | | Comportamento | Argumento | | - | - | - | | Then | **Add Response Cookie** | `cookie-host-value=${host}` | Quando esta regra for ativada, se a requisição for feita do host determinado no criteria, a resposta retornará o cabeçalho com o seguinte valor: `Set-Cookie: cookie-host-value=host.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 **Behaviors**: | Variável | Descriçã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 | Utilize o behavior *Add Response Cookie* com o argumento `cookie-name=cookie-value; Expires=${cookie_time_offset(3600)}` para determinar o TTL do cookie expire em 1 hora a partir do momento que for criado | | `${encode_base64(string)}` | Retorna o argumento codificado em base64 | `${encode_base64 (www.domain.com)}` assume `d3d3LmRvbWFpbi5jb20K` | ### Operadores de comparação | Operador | Descrição | Tipo de argumento | | --- | --- | --- | | is equal | O valor da variável é igual ao argumento, comparado caractere a caractere | string | | is not equal | O valor da variável não é exatamente igual ao argumento | string | | starts with | O valor da variável inicia pelo argumento | string | | does not start with | O valor da variável não inicia pelo argumento | string | | matches | O valor da variável coincide com a expressão regular informada como argumento | regular expression | | does not match | O valor da variável não coincide com a expressão regular informada como argumento | regular expression | | exists | A variável tem valor definido. Exemplo: `${arg_search}` existe se foi enviado um argumento *search* na query string da requisição | - | | does not exist | A variável não tem valor definido. Exemplo: `${arg_search}` não existe se não foi enviado um argumento *search* na query string da requisição | - | :::note Esses operadores podem variar de acordo com os Critérios selecionados. ::: ### Operadores lógicos 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. :::note 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**. --- ## Behaviors 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: | Comportamento | Argumento | | --- | --- | | 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. ### Add Cookie Request Phase Response Phase [Requer Application Accelerator](/pt-br/documentacao/produtos/build/applications/application-accelerator/) 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](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie) ao argumento, separadas do valor do cookie por ponto e vírgula (`;`): - `Expires=date` (EEE, d MMM yyyy HH:mm:ss 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}`. ### Add Header 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`. :::tip O field `name` pode conter apenas letras (a-z, A-Z), números (0-9), hífens (-) e underlines (_). O uso de qualquer outro caractere tornará o cabeçalho inválido. ::: | Campo do cabeçalho | Caracteres permitidos | | ------------ | ----------------------------------------------------- | | Name | (a-z, A-Z, 0-9), (-, _ ) | | Value | (a-z, A-Z, 0-9), (\_ :;.,\/"'?!(){}[]@<>=-+*#$&`\|~^%) | :::caution O valor do argumento está limitado a **1.600 caracteres**. Exceder esse limite retorna o erro `Argument too long`. ::: Por exemplo, este seria um cabeçalho válido: ``` example-field: example-value! ``` ### Filtrar Header Request Phase Response Phase Remove um cabeçalho de requisição que seria enviado para a origem ou um cabeçalho de resposta que seria enviado para o usuário. O nome do campo do cabeçalho deve ser inserido como um argumento, por exemplo: `Nome-do-Cabeçalho`. :::caution[Atenção] Os seguintes cabeçalhos não podem ser sobrescritos nem filtrados: - Host - Connection - Range - X-Forward-For - Cdn-Loop ::: ### Bypass Cache Request Phase [Requer Application Accelerator](/pt-br/documentacao/produtos/build/applications/application-accelerator/) 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](#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. :::tip Consulte o guia [Como configurar a políticas de cache para Applications](/pt-br/documentacao/produtos/guias/cache-settings/#bypass-cache) para mais informações sobre o uso de Bypass Cache. ::: ### Diferença 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. :::tip Você pode definir o TTL como zero se o conteúdo dinâmico, que varia em um determinado tempo, puder ser entregue de forma idêntica a todos os usuários que fizerem solicitações simultâneas. ::: ### Capture Match Groups Request Phase Response Phase [Requer Application Accelerator](/pt-br/documentacao/produtos/build/applications/application-accelerator/) 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 o 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*: `^(?.*/)(?[^/]*)$` ### Deliver 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. ### Deny (403 Forbidden) 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. ### Enable Gzip 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](/pt-br/documentacao/produtos/guias/gzip-compression/) para mais informações. ### Enable Large File Optimization Request Phase [Requer Cache](/pt-br/documentacao/produtos/build/applications/cache/) Ativa segmentação de objetos grandes em fragmentos, caso sua origem tenha suporte a requisições HTTP byte-range. Utilize este behavior se você entrega objetos 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](/pt-br/documentacao/produtos/build/applications/cache-settings/#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. ### Enforce HLS cache 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`). ### Filter Cookie Request Phase Response Phase [Requer Application Accelerator](/pt-br/documentacao/produtos/build/applications/application-accelerator/) 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`. ### Filter Header 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`. ### Finish Request Phase Request Phase Finaliza a fase de requisição. Qualquer comportamento ou regra abaixo desse comportamento não será executada. ### Forward Cookies Request Phase [Requer Application Accelerator](/pt-br/documentacao/produtos/build/applications/application-accelerator/) 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](/pt-br/documentacao/produtos/guias/cache-settings/#criando-uma-regra-para-enviar-cookies-da-origem-ao-usuario). #### JavaScript Cookies 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](https://www.w3schools.com/js/js_cookies.asp) deve possuir o seguinte formato: ```js 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. ### No Content (204) Request Phase Retorna um código `204` quando se faz um request à aplicação ao invés do código recebido da origem. ### Optimize Images Request Phase [Requer Image Processor](/pt-br/documentacao/produtos/build/applications/image-processor/) Ativa a otimização de imagens. ### Redirect HTTP to HTTPS Request Phase [Requer aplicação HTTPS](/pt-br/documentacao/produtos/build/applications/main-settings/) Redireciona a requisição HTTP para a respectiva URL em HTTPS. Caso a requisição já seja HTTPS, não executa nenhum comportamento. ### Redirect To 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. :::caution Na Response Phase, os behaviors Redirect To serão executados apenas quando a origem retorna um erro 404. ::: ### Rewrite Request Request Phase [Requer Application Accelerator](/pt-br/documentacao/produtos/build/applications/application-accelerator/) 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/(.*)` 2. Utilizar o behavior **Rewrite Request** com o argumento `/new/%{capture[1]}` ### Run Function Request Phase Response Phase [Requer Application Accelerator](/pt-br/documentacao/produtos/build/applications/application-accelerator/) [Requer Functions](/pt-br/documentacao/produtos/build/applications/functions/) Executa uma função criada no **Functions** e instanciada pela aba **Functions** da application. Consulte o guia de [Como executar funções serverless](/pt-br/documentacao/produtos/guias/funcoes-serverless/) para mais informações. ### Set Cache Policy 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](/pt-br/documentacao/produtos/build/applications/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](/pt-br/documentacao/produtos/build/applications/cache-settings/#advanced-cache-key). ### Set Origin Request Phase Atribui a origem que deve ser consultada pelo edge node para a requisição. As origens devem ser previamente configuradas usando [Origins](/pt-br/documentacao/produtos/build/applications/origins/). --- ## Execução e lógica de behaviors --- ## Debug de regras Você pode executar o fazer o [debug de regras criadas com Rules Engine](/pt-br/documentacao/produtos/guias/debug-regras/) usando **GraphQL API**, **Data Stream** ou **Real-Time Events**. --- ## Limites :::tip **Aumente limites**

Você pode solicitar o aumento dos limites com base no seu plano. Contate o [time de suporte técnico](/pt-br/documentacao/servicos/suporte/) para fazer a solicitação. ::: Estes são os **limites default**: | Escopo | Limites | | --- | --- | | Regras (request ou response) | 200 | | Criteria por regra | 5 | | Behaviors por regra | 10 | | Variables por criteria | 10 | | Argumento de behavior | 1.600 caracteres | :::tip O limite total é de 200 regras, distribuídas entre **requests** e **responses**. Por exemplo, você pode ter 150 regras de request e 50 de response. :::