Compartilhar via

Reescrever cabeçalhos HTTP e URL com o Gateway de Aplicativo

  • Artigo

O Gateway de Aplicativo permite que você reescreva o conteúdo selecionado de solicitações e respostas. Com esse recurso, você pode traduzir URLs, parâmetros de cadeia de caracteres de consulta e modificar cabeçalhos de solicitação e resposta. Ele também permite adicionar condições para garantir que o URL ou os cabeçalhos especificados sejam reescritos apenas quando determinadas condições forem atendidas. Essas condições se baseiam nas informações de solicitação e resposta.

Observação

Os recursos de reescrita de cabeçalho HTTP e de URL estão disponíveis somente para a SKU do Gateway de Aplicativo v2

Tipos de reescrita compatíveis

Cabeçalhos de solicitação e resposta

Os cabeçalhos HTTP permitem que um cliente e um servidor passem informações adicionais com uma solicitação ou resposta. Ao reescrever esses cabeçalhos, você pode realizar tarefas importantes, como adicionar campos de cabeçalho relacionados à segurança, como HSTS/X-XSS-Protection, remover campos de cabeçalho de resposta que podem revelar informações confidenciais e remover informações de porta de cabeçalhos X-Forwarded-For.

O Gateway de Aplicativo permite adicionar, remover ou atualizar solicitações HTTP e cabeçalhos de resposta, enquanto os pacotes de solicitação e resposta são transferidos entre os pools de cliente e de back-end.

Para saber como reescrever cabeçalhos de solicitação e de resposta com o Gateway de Aplicativo usando o portal do Azure, consulte aqui.

Um diagrama mostra os cabeçalhos em pacotes de solicitação e resposta.

Cabeçalhos compatíveis

Você pode reescrever todos os cabeçalhos em solicitações e respostas, exceto para os cabeçalhos Conexão e Atualização. Você também pode usar o gateway de aplicativo para criar cabeçalhos personalizados e adicioná-los às solicitações e respostas que estão sendo roteadas por ele.

Caminho de URL e cadeia de caracteres de consulta

Com a capacidade de reescrita de URL no Gateway de Aplicativo, você pode:

  • Reescrever o nome do host, o caminho e a cadeia de caracteres de consulta da URL de solicitação

  • Escolha reescrever a URL de todas as solicitações em um ouvinte ou apenas aquelas solicitações que correspondem a uma ou mais das condições que você definir. Essas condições são baseadas nas propriedades de solicitação (cabeçalho da solicitação e variáveis do servidor).

  • Escolher rotear a solicitação (selecione o pool de back-end) com base na URL original ou na URL reescrita

Para saber como reescrever a URL com o Gateway de Aplicativo usando o portal do Azure, consulte aqui.

Diagrama que descreve o processo de reescrita de uma URL com o Gateway de Aplicativo.

Ações de reescrita

As ações de reescrita são usadas para especificar a URL. Além de permitir a reescrita de cabeçalhos de solicitação ou resposta e o novo valor de destino da URL. Você pode definir o valor de uma URL ou de um cabeçalho, novo ou existente, para os seguintes tipos de valores:

  • Texto
  • Cabeçalho da solicitação. Para especificar um cabeçalho de solicitação, você precisa usar a sintaxe {http_req_headerName}
  • Cabeçalho de resposta. Para especificar um cabeçalho de resposta, você precisa usar a sintaxe {http_resp_headerName}
  • Variável de servidor. Para especificar uma variável de servidor, você precisa usar a sintaxe {var_serverVariable}. Consulte a lista de variáveis de servidor compatíveis
  • Uma combinação de texto, um cabeçalho de solicitação, um cabeçalho de resposta e uma variável de servidor.

Condições de reescrita

Você pode usar condições de reescrita para avaliar o conteúdo de solicitações e respostas HTTP(S). Essa configuração opcional permite que você execute uma reescrita apenas quando uma ou mais condições forem atendidas. O gateway de aplicativo usa esses tipos de variáveis para avaliar o conteúdo de solicitações e respostas:

  • Cabeçalhos HTTP na solicitação
  • Cabeçalhos HTTP na resposta
  • Variáveis de servidor do Gateway de Aplicativo

Você pode usar uma condição para avaliar se uma variável especificada está presente, se uma variável especificada corresponde a um valor específico ou se uma variável especificada corresponde a um padrão específico.

Correspondência padrão

O Gateway de Aplicativo usa expressões regulares para correspondência de padrões na condição. Você deve usar expressões compatíveis com RE2 (Expressão Regular 2) ao escrever suas condições. Se você estiver executando um WAF (Firewall de Aplicativo Web) do Gateway de Aplicativo com o Core Rule Set 3.1 ou anterior, poderá enfrentar problemas ao usar Expressões Regulares Compatíveis com Perl (PCRE). É possível ocorrer problemas ao usar declarações lookahead e lookbehind (negativas ou positivas).

Capturando

Para capturar uma subcadeia de caracteres para uso posterior, coloque parênteses em volta do subpadrão correspondente na definição de regex da condição. O primeiro par de parênteses armazena sua subcadeia de caracteres em 1, o segundo par em 2 e assim por diante. Você pode usar quantos parênteses desejar; o Perl continua definindo mais variáveis ​​numeradas para você representar essas cadeias de caracteres capturadas. Alguns exemplos de ref:

  • /(\d)(\d)/ # Corresponder dois dígitos, capturando-os nos grupos 1 e 2

  • /(\d+)/ # Corresponder um ou mais dígitos, capturando todos eles no grupo 1

  • /(\d+)/ # Corresponder um dígito uma ou mais vezes, capturando o último no grupo 1

Observação

O uso de / para prefixar e sufixar o padrão não deve ser especificado no valor do padrão a ser correspondido. Por exemplo, (\d)(\d) corresponde a dois dígitos. /(\d) (\d)/ não corresponderá a dois dígitos.

Depois de capturados, você pode referenciá-los no conjunto de ações usando o seguinte formato:

  • Para uma captura de cabeçalho de solicitação, você deve usar {http_req_headerName_groupNumber}. Por exemplo, {http_req_User-Agent_1} ou {http_req_User-Agent_2}
  • Para uma captura de cabeçalho de resposta, você deve usar {http_resp_headerName_groupNumber}. Por exemplo, {http_resp_Location_1} ou {http_resp_Location_2}
  • Para uma variável de servidor, você deve usar {var_serverVariableName_groupNumber}. Por exemplo, {var_uri_path_1} ou {var_uri_path_2}

Observação

O caso da variável de condição precisa corresponder ao caso da variável de captura. Por exemplo, se a variável de condição for user-agent, a variável de captura precisará ser para user-agent (ou seja, {http_req_user-agent_2}).

Se você quiser usar o valor inteiro, não deverá mencionar o número. Basta usar o formato {http_req_headerName} etc. sem o groupNumber.

Variáveis de servidor

O Gateway de Aplicativo usa variáveis de servidor para armazenar informações úteis sobre o servidor, a conexão com o cliente e a solicitação atual na conexão. Exemplos de informações armazenadas incluem o endereço IP do cliente e o tipo de navegador da Web. As variáveis de servidor são alteradas dinamicamente, por exemplo, quando uma nova página é carregada ou quando um formulário é postado. Você pode usar essas variáveis para avaliar as condições de reescrita e reescrever cabeçalhos. Para reescrever cabeçalhos usando variáveis de servidor, especifique essas variáveis na sintaxe {var_serverVariableName}

O Gateway de Aplicativo dá suporte às seguintes variáveis de servidor:

Nome da variável Descrição
add_x_forwarded_for_proxy O campo de cabeçalho de solicitação de cliente X-Forwarded-For com a variável client_ip (consulte a explicação mais adiante nesta tabela) anexada a ele no formato IP1, IP2, IP3 e assim por diante. Se o campo X-Forwarded-For não estiver no cabeçalho de solicitação do cliente, a variável add_x_forwarded_for_proxy será igual à variável $client_ip. Essa variável é útil para reescrever o cabeçalho X-Forwarded-For definido pelo Gateway de Aplicativo para que o cabeçalho contenha apenas o endereço IP, sem informações de porta.
ciphers_supported Uma lista das criptografias que têm suporte do cliente.
ciphers_used A cadeia de caracteres de criptografias usadas para uma conexão TLS estabelecida.
client_ip O endereço IP do cliente a partir do qual o gateway de aplicativo recebeu a solicitação. Se houver um proxy reverso antes do gateway de aplicativo e do cliente de origem, client_ip retornará o endereço IP do proxy reverso.
client_port A porta do cliente.
client_tcp_rtt Informações sobre a conexão TCP do cliente. Disponível em sistemas que suportam a opção de soquete TCP_INFO.
client_user Quando a autenticação HTTP é usada, o nome de usuário fornecido para autenticação.
host Nesta ordem de precedência: o nome do host na linha de solicitação, o nome do host no campo de cabeçalho de solicitação de Host ou o nome do servidor que corresponde a uma solicitação. Exemplo, na solicitação http://contoso.com:8080/article.aspx?id=123&title=fabrikam, o valor de host é contoso.com
cookie_name O cookie name.
http_method O método usado para fazer a solicitação de URL. Por exemplo, GET ou POST.
http_status O status da sessão. Por exemplo, 200, 400 ou 403.
http_version O protocolo de solicitação. Geralmente, HTTP/1.0, HTTP/1.1 ou HTTP/2.0.
query_string A lista de pares variável/valor que seguem o "?" na URL solicitada. Exemplo: na solicitação http://contoso.com:8080/article.aspx?id=123&title=fabrikam, o valor de query_string é id=123&title=fabrikam
received_bytes O comprimento da solicitação (incluindo a linha da solicitação, o cabeçalho e o corpo da solicitação).
request_query Os argumentos na linha da solicitação.
request_scheme O esquema de solicitação: http ou https.
request_uri A URI da solicitação original completa (com argumentos). Exemplo: na solicitação http://contoso.com:8080/article.aspx?id=123&title=fabrikam*, o valor de request_uri é /article.aspx?id=123&title=fabrikam
sent_bytes O número de bytes enviados a um cliente.
server_port A porta do servidor que aceitou uma solicitação.
ssl_connection_protocol O protocolo de uma conexão TLS estabelecida.
ssl_enabled "Ativado" se a conexão opera no modo TLS. Caso contrário, uma cadeia de caracteres vazia.
uri_path Identifica o recurso específico no host que o cliente Web deseja acessar. A variável refere-se ao caminho do URL original, antes de qualquer manipulação. Essa é a parte da URI de solicitação sem os argumentos. Por exemplo, na solicitação http://contoso.com:8080/article.aspx?id=123&title=fabrikam, o valor uri_path é /article.aspx.

Variáveis do servidor de autenticação mútua

O Gateway de Aplicativo dá suporte às seguintes variáveis de servidor para cenários de autenticação mútua. Use essas variáveis de servidor da mesma maneira que acima com as outras variáveis de servidor.

Nome da variável Descrição
client_certificate O certificado do cliente em formato PEM para uma conexão SSL estabelecida.
client_certificate_end_date A data de término do certificado do cliente.
client_certificate_fingerprint A impressão digital SHA1 do certificado do cliente para uma conexão SSL estabelecida.
client_certificate_issuer A cadeia de caracteres "DN do emissor" do certificado do cliente para uma conexão SSL estabelecida.
client_certificate_serial O número de série do certificado do cliente para uma conexão SSL estabelecida.
client_certificate_start_date A data de início do certificado do cliente.
client_certificate_subject A cadeia de caracteres "DN da entidade" do certificado do cliente para uma conexão SSL estabelecida.
client_certificate_verification O resultado da verificação do certificado do cliente: ÊXITO, FALHA:<reason> ou NENHUM se um certificado não estiver presente.

Configuração da reescrita

Para configurar uma regra de reescrita, você precisa criar um conjunto de regras de reescrita e adicionar a configuração da regra de reescrita nele.

Um conjunto de regras de reescrita contém:

  • Associação da regra de roteamento da solicitação: A configuração da reescrita está associada ao ouvinte de origem por meio da regra de roteamento. Quando você usa uma regra de roteamento básica, a configuração de reescrita é associada a um ouvinte de origem e é uma reescrita de cabeçalho global. Quando você usa uma regra de roteamento com base em caminho, a configuração de reescrita é definida no mapa de caminho da URL. Nesse caso, ela se aplica somente à área de caminho específico de um site. Você pode criar vários conjuntos de reescrita e aplicar cada conjunto de reescrita a vários ouvintes. Mas você pode aplicar apenas um conjunto de reescrita a um ouvinte específico.

  • Condição de reescrita: essa configuração é opcional. As condições de reescrita avaliam o conteúdo das solicitações e respostas HTTP(S). A ação de reescrita ocorre se a solicitação ou resposta HTTP(S) corresponder à condição de reescrita. Se você associar mais de uma condição a uma ação, a ação ocorrerá somente quando todas as condições forem atendidas. Em outras palavras, a operação é uma operação AND lógica.

  • Tipo de reescrita: há 3 tipos de reescritas disponíveis:

    • Reescrita de cabeçalhos de solicitação
    • Reescrita de cabeçalhos de resposta
    • Reescrita de componentes de URL
      • Caminho da URL: o valor para o qual o caminho deve ser reescrito.
      • Cadeia de caracteres de consulta da URL: o valor para o qual a cadeia de caracteres de consulta deve ser reescrita.
      • Reavaliar o mapa do caminho: usado para determinar se o mapa do caminho da URL deve ser reavaliado ou não. Se mantido desmarcado, o caminho da URL original é usado para corresponder ao padrão do caminho no mapa do caminho da URL. Se definido como verdadeiro, o mapa do caminho da URL é reavaliado para verificar a correspondência com o caminho reescrito. Habilitar essa opção ajuda a rotear a solicitação para um pool de back-end diferente após a reescrita.

Reescrever as armadilhas comuns da configuração

  • Não é permitido habilitar a opção "Reavaliar o mapa do caminho" para as regras básicas de roteamento de solicitações. Isso evita um loop infinito de avaliação para uma regra básica de roteamento.

  • Deve haver, pelo menos, uma regra de reescrita condicional ou uma regra de reescrita sem a opção "Reavaliar mapa do caminho" habilitada para as regras de roteamento baseadas em caminho. Isso evita um loop infinito de avaliação para uma regra de roteamento baseada em caminho.

  • As solicitações de entrada seriam encerradas com um código de erro 500 caso um loop fosse criado dinamicamente com base nas entradas do cliente. O Gateway de Aplicativo continuará a atender outras solicitações sem degradações nesse cenário.

Usando a reescrita de URL ou a reescrita de cabeçalho de host com o Firewall do Aplicativo Web (WAF_v2 SKU)

Quando você configurar a reescrita de URL ou a reescrita do cabeçalho de host, o WAF avaliará a solicitação após a modificação do cabeçalho da solicitação ou dos parâmetros da URL (pós-reescrita). E quando você remover a configuração da reescrita de URL ou do cabeçalho de host no seu Gateway de Aplicativo, o WAF fará a avaliação antes da reescrita do cabeçalho (pré-reescrita). Essa ordem garante que as regras do WAF sejam aplicadas à solicitação final que seria recebida pelo seu pool de back-end.

Por exemplo, digamos que você tenha a seguinte regra de reescrita de cabeçalho para o cabeçalho "Accept" : "text/html" - se o valor do cabeçalho "Accept" for igual a "text/html", reescreva o valor para "image/png".

Aqui, com apenas a reescrita de cabeçalho configurada, o WAF fará a avaliação em "Accept" : "text/html". Mas quando você configurar a reescrita de URL ou a reescrita do cabeçalho de host, o WAF fará a avaliação em "Accept" : "image/png".

Cenários comuns de reescrita de cabeçalho

Remover informações da porta do cabeçalho X-Forwarded-For

O Gateway de Aplicativo insere um cabeçalho X-Forwarded-For em todas as solicitações antes de encaminhar as solicitações ao back-end. Esse cabeçalho é uma lista separada por vírgulas de portas IP. Pode haver cenários nos quais os servidores back-end só precisam que os cabeçalhos contenham endereços IP. Você pode usar a reescrita de cabeçalho para remover informações da porta do cabeçalho X-Forwarded-For. Uma maneira de fazer isso é definir o cabeçalho para a variável de servidor add_x_forwarded_for_proxy. Como alternativa, você também pode usar a variável client_ip:

Captura de tela mostrando uma ação de remoção de porta.

Modificar uma URL de redirecionamento

A modificação de uma URL de redirecionamento pode ser útil em determinadas circunstâncias. Por exemplo: os clientes foram originalmente redirecionados para um caminho como "/blog", mas agora devem ser enviados para "/updates" devido a uma alteração na estrutura de conteúdo.

Aviso

Às vezes, a necessidade de modificar uma URL de redirecionamento é exibida no contexto de uma configuração na qual o Gateway de Aplicativo está configurado para substituir o nome do host em direção ao back-end. O nome do host como visto pelo back-end é nesse caso diferente do nome do host, como visto pelo navegador. Nessa situação, o redirecionamento não usará o nome de host correto. Esta configuração não é recomendada.

As limitações e as implicações dessa configuração são descritas em Preservar o nome do host HTTP original entre um proxy reverso e o aplicativo Web de back-end. A configuração recomendada para Serviço de Aplicativo é seguir as instruções para "Custom Domain (recomendado)" em Configurar Serviço de Aplicativo com Gateway de Aplicativo. A reescrita do cabeçalho de local na resposta, conforme descrito no exemplo abaixo, deve ser considerada uma solução alternativa e não resolve a causa raiz.

Quando o serviço de aplicativo envia uma resposta de redirecionamento, ele usa o mesmo nome de host no cabeçalho do local da sua resposta e na solicitação que recebe do gateway de aplicativo. Portanto, o cliente fará a solicitação diretamente para contoso.azurewebsites.net/path2 em vez de passar pelo gateway de aplicativo (contoso.com/path2). Ignorar o gateway de aplicativo não é desejável.

Você pode resolver esse problema definindo o nome do host no cabeçalho do local como o nome de domínio do gateway de aplicativo.

Veja aqui as etapas para substituir o nome do host:

  1. Crie uma regra de reescrita com uma condição que avalie se o cabeçalho do local na resposta contém azurewebsites.net. Insira o padrão (https?):\/\/.*azurewebsites\.net(.*)$.

  2. Execute uma ação para reescrever o cabeçalho do local para que ele tenha o nome do host do gateway de aplicativo. Faça isso inserindo {http_resp_Location_1}://contoso.com{http_resp_Location_2} como o valor do cabeçalho. Como alternativa, você também pode usar a variável de servidor host para definir o nome do host para corresponder à solicitação original.

    Captura de tela da ação de modificação do cabeçalho de localização.

Implementar cabeçalhos HTTP de segurança para evitar vulnerabilidades

Você pode corrigir várias vulnerabilidades de segurança implementando os cabeçalhos necessários na resposta do aplicativo. Esses cabeçalhos de segurança incluem X-XSS-Protection, Strict-Transport-Security e Content-Security-Policy. Você pode usar o Gateway de Aplicativo para definir esses cabeçalhos para todas as respostas.

Captura de tela de um cabeçalho de segurança.

Excluir cabeçalhos indesejados

Talvez você queira remover os cabeçalhos que revelam informações confidenciais de uma resposta HTTP. Por exemplo, o ideal é remover informações como o nome do servidor back-end, o sistema operacional ou os detalhes da biblioteca. Você pode usar o gateway de aplicativo para remover estes cabeçalhos:

Captura de tela mostrando a ação de exclusão de cabeçalho.

Não é possível criar uma regra de reescrita para excluir o cabeçalho de host. Se você tentar criar uma regra de reescrita com o tipo de ação definido como "excluir" e o cabeçalho definido como "host", isso resultará em um erro.

Verificar a presença de um cabeçalho

Você pode avaliar um cabeçalho de solicitação ou de resposta HTTP quanto à presença de um cabeçalho ou variável de servidor. Essa avaliação é útil quando você deseja executar uma reescrita de cabeçalho somente quando um determinado cabeçalho está presente.

Captura de tela mostra a ação de verificação de presença de um cabeçalho.

Cenários comuns de reescrita de URL

Seleção de caminho baseado em parâmetro

Para obter cenários em que você escolhe o pool de back-end com base no valor de um cabeçalho, parte da URL ou cadeia de caracteres de consulta na solicitação, você pode usar uma combinação de capacidade de reescrita de URL e roteamento baseado em caminho.

Para fazer isso, crie um conjunto de reescrita com uma condição que verifica um parâmetro específico (cadeia de caracteres de consulta, cabeçalho etc.) e, em seguida, execute uma ação em que isso altera o caminho da URL (verifique se Reavaliar o mapa do caminho está habilitado). Em seguida, o conjunto de reescrita deve ser associado a uma regra baseada em caminho. A regra baseada em caminho deve conter os mesmos caminhos de URL especificados no conjunto de reescrita e no pool de back-end correspondente.

Assim, o conjunto de reescrita permite que os usuários verifiquem um parâmetro específico e atribuam a ele um novo caminho, e a regra baseada em caminho permite que os usuários atribuam pools de back-end a esses caminhos. Se "Reavaliar o mapa do caminho" estiver habilitado, o tráfego será roteado com base no caminho especificado no conjunto de reescrita.

Para obter um exemplo de caso de uso usando cadeias de caracteres de consulta, consulte Rotear o tráfego usando a seleção de caminho baseado em parâmetro no portal.

Reescrever parâmetros de cadeia de caracteres de consulta com base na URL

Considere um cenário de um site de compras no qual o link visível ao usuário deve ser simples e legível, mas o servidor back-end precisa dos parâmetros da cadeia de caracteres de consulta para mostrar o conteúdo correto.

Nesse caso, o Gateway de Aplicativo pode capturar parâmetros da URL e adicionar pares chave-valor de cadeia de caracteres de consulta a partir daqueles da URL. Por exemplo, digamos que o usuário deseja reescrever, https://www.contoso.com/fashion/shirts para https://www.contoso.com/buy.aspx?category=fashion&product=shirts. Isso pode ser feito por meio da configuração de reescrita de URL a seguir.

Condição - Se a variável de servidor uri_path for igual ao padrão /(.+)/(.+)

Cenário de reescrita de URL 2-1.

Ação - Defina o caminho da URL para buy.aspx e a cadeia de caracteres de consulta para category={var_uri_path_1}&product={var_uri_path_2}

Cenário de reescrita de URL 2-2.

Para obter um guia passo a passo para obter o cenário descrito acima, consulte Reescrever URL com o Gateway de Aplicativo usando o portal do Azure

Reescrita de URL versus Redirecionamento de URL

No caso da reescrita de URL, o Gateway de Aplicativo reescreve a URL antes que a solicitação seja enviada ao back-end. Isso não vai alterar o que os usuários veem no navegador, pois as alterações ficam ocultas do usuário.

No caso do redirecionamento de URL, o Gateway de Aplicativo envia uma resposta de redirecionamento ao cliente com a nova URL. Isso, por sua vez, exige que o cliente reenvie sua solicitação para a nova URL fornecida no redirecionamento. A URL que o usuário vê no navegador será atualizada para a nova URL.

Reescrita versus Redirecionamento.

Limitações

  • Se uma resposta tiver mais de um cabeçalho com o mesmo nome, reescrever o valor de um desses cabeçalhos descartará os outros cabeçalhos na resposta. Isso pode acontecer com o cabeçalho Set-Cookie, pois você pode ter mais de um cabeçalho Set-Cookie em uma resposta. Um cenário desse tipo é quando você está usando um serviço de aplicativo com um gateway de aplicativo e configurou a afinidade de sessão baseada em cookie no gateway de aplicativo. Nesse caso, a resposta incluem dois cabeçalhos Set-Cookie. Por exemplo: um usado pelo serviço de aplicativo Set-Cookie: ARRAffinity=ba127f1caf6ac822b2347cc18bba0364d699ca1ad44d20e0ec01ea80cda2a735;Path=/;HttpOnly;Domain=sitename.azurewebsites.net, e outro para afinidade do gateway de aplicativo, Set-Cookie: ApplicationGatewayAffinity=c1a2bd51lfd396387f96bl9cc3d2c516; Path=/. Reescrever um dos cabeçalhos Set-Cookie nesse cenário pode resultar na remoção do outro cabeçalho Set-Cookie da resposta.
  • Não há suporte para reescritas quando o gateway de aplicativo está configurado para redirecionar as solicitações ou para mostrar uma página de erro personalizada.
  • Os nomes de cabeçalho de solicitação podem conter caracteres alfanuméricos e hifens. Os nomes de cabeçalhos que contiverem outros caracteres serão descartados ao enviar uma solicitação para o destino de back-end.
  • Os nomes de cabeçalhos podem conter qualquer caractere alfanumérico e símbolos específicos, conforme definido no RFC 7230.
  • Os cabeçalhos de conexão e atualização não podem ser reescritos
  • Não há suporte para reescritas em respostas 4xx e 5xx geradas diretamente do Gateway de Aplicativo

Próximas etapas