From: Rich Bowen <rbowen@apache.org>
Date: Wed, 13 May 2026 19:37:51 +0000 (+0000)
Subject: pt-br translation: new files and updated htaccess, contributed by Leonardo Lara Rodrigues
X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=95c8b81bb054efdd5619988858ae9c2dff03e304;p=thirdparty%2Fapache%2Fhttpd.git

pt-br translation: new files and updated htaccess, contributed by Leonardo Lara Rodrigues

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1934175 13f79535-47bb-0310-9956-ffa450edef68
---

diff --git a/docs/manual/bind.xml.pt-br b/docs/manual/bind.xml.pt-br
new file mode 100644
index 0000000000..c2bd8af00a
--- /dev/null
+++ b/docs/manual/bind.xml.pt-br
@@ -0,0 +1,241 @@
+<?xml version="1.0" encoding="UTF-8" ?>
+<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
+<?xml-stylesheet type="text/xsl" href="./style/manual.pt-br.xsl"?>
+<!-- English Revision: 1933438 -->
+<!-- Portuguese(BR) translation: leonardolara --><!-- Reviewed by: leonardolara -->
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements.  See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License.  You may obtain a copy of the License at
+
+     http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<manualpage metafile="bind.xml.meta">
+
+  <title>Vinculando a Endereços e Portas</title>
+
+  <summary>
+    <p>Configurando o Servidor HTTP Apache para escutar em endereços e portas específicas.</p>
+  </summary>
+
+  <seealso><a href="vhosts/">Hosts Virtuais</a></seealso>
+  <seealso><a href="dns-caveats.html">Problemas com DNS</a></seealso>
+
+  <section id="overview">
+    <title>Visão Geral</title>
+
+    <related>
+      <modulelist>
+        <module>core</module>
+        <module>mpm_common</module>
+      </modulelist>
+      <directivelist>
+        <directive module="core" type="section">VirtualHost</directive>
+        <directive module="mpm_common">Listen</directive>
+      </directivelist>
+    </related>
+
+
+    <p>Quando o httpd inicia, ele se vincula a algumas portas e endereços na
+    máquina local e aguarda por requisições entrantes. Por padrão,
+    ele monitora todos os endereços na máquina. No entanto, pode ser necessário
+    monitoramento em portas específicas ou somente em
+    endereços selecionados, ou uma combinação dos dois. Isto é muitas vezes combinado com
+    o recurso de <a href="vhosts/">Host Virtual</a>, que determina como o
+    <code>httpd</code> responde a endereços, nomes de hosts e portas
+    diferentes.</p>
+
+    <p>A diretiva <directive module="mpm_common">Listen</directive>
+    informa ao servidor que ele deve aceitar
+    requisições entrantes apenas na(s) porta(s) especificada(s) ou
+    em combinações de endereço e porta. Se apenas um número de porta for
+    especificado na diretiva <directive module="mpm_common">Listen</directive>,
+    o servidor monitora a porta informada em todas as interfaces.
+    Se um endereço IP é informado junto com uma porta, o servidor irá monitorar
+    na porta e na interface especificadas. Múltiplas diretivas <directive
+    module="mpm_common">Listen</directive> podem ser usadas para
+    especificar vários endereços e portas para monitoramento. O
+    servidor responderá a requisições de quaisquer dos endereços e
+    portas listados.</p>
+
+    <p>Por exemplo, para que o servidor aceite conexões tanto na
+    porta 80 quanto na 8000, em todas as interfaces, use:</p>
+
+    <example>
+    <highlight language="config">
+Listen 80
+Listen 8000
+    </highlight>
+    </example>
+
+    <p>Para que o servidor aceite conexões na porta 80 para uma interface
+       e na porta 8000 para outra, use:</p>
+
+    <example>
+    <highlight language="config">
+Listen 192.0.2.1:80
+Listen 192.0.2.5:8000
+    </highlight>
+    </example>
+
+    <p>Endereços IPv6 precisam ser envolvidos por colchetes, como no
+    exemplo a seguir:</p>
+
+    <example>
+    <highlight language="config">
+      Listen [2001:db8::a00:20ff:fea7:ccea]:80
+    </highlight>
+    </example>
+
+    <note type="warning"><p>A sobreposição de diretivas <directive
+    module="mpm_common">Listen</directive> resultará em um
+    erro fatal que irá impedir o servidor de iniciar.</p>
+
+    <example>
+      (48)Address already in use: make_sock: could not bind to address [::]:80
+    </example>
+
+    <p>Consulte esta <a
+    href="https://cwiki.apache.org/confluence/display/httpd/CouldNotBindToAddress">discussão
+    na wiki</a> para mais dicas de soluções de problemas.</p>
+
+</note>
+
+  </section>
+
+  <section id="reload">
+    <title>Alterando a configuração de Listen no reinício</title>
+
+    <p>Quando o httpd é reiniciado, uma consideração especial precisa ser feita para
+    alterações a diretivas <directive module="mpm_common">Listen</directive>. Durante um reinício, o httpd mantém as portas
+    vinculadas (como na configuração original) para evitar a geração de erros
+    "Connection refused" (conexão recusada) para quaisquer novas tentativas de conexão
+    ao servidor. Se as alterações são feitas no conjunto de diretivas <directive module="mpm_common">Listen</directive>
+    que conflitam com a configuração antiga, a configuração irá falhar
+    e o servidor irá terminar.</p>
+
+    <p>Por exemplo, alterando da configuração:</p>
+
+    <example>
+    <highlight language="config">
+      Listen 127.0.0.1:80
+    </highlight>
+    </example>
+
+    <p>para a configuração a seguir pode falhar, porque a vinculação da porta 80 para
+    todos os endereços conflita com a vinculação da porta 80 somente para
+    127.0.0.1.</p>
+
+    <example>
+    <highlight language="config">
+      Listen 80
+    </highlight>
+    </example>
+
+    <p>Para que tal configuração tenha efeito, é necessário
+    parar e depois iniciar o servidor.</p>
+
+  </section>
+
+    <section id="ipv6">
+    <title>Considerações Especiais sobre IPv6</title>
+
+    <p>Um número crescente de plataformas implementa IPv6 e o
+    <glossary>APR</glossary> suporta IPv6 na maioria delas,
+    permitindo que o httpd aloque soquetes IPv6 e manipule requisições enviadas
+    através de IPv6.</p>
+
+    <p>Um fator complicador para administradores de httpd é definir se
+    um soquete IPv6 pode lidar tanto com conexões IPv4 quanto com
+    IPv6. Lidar com conexões IPv4 com soquete IPv6 usa
+    endereços IPv6 mapeados para IPv4, o que é permitido por padrão na maioria
+    das plataformas mas é proibido por padrão no FreeBSD, NetBSD e
+    OpenBSD, para alinhamento com a política de sistema dessas
+    plataformas. Em sistemas onde isso é proibido por padrão, um
+    parâmetro especial do programa <program>configure</program> pode alterar este
+    comportamento para o httpd.</p>
+
+    <p>Por outro lado, em algumas plataformas como Linux e Tru64, a
+    <strong>única</strong> forma de lidar tanto com IPv6 quanto com IPv4 é usar
+    endereços mapeados. Se o <code>httpd</code> tiver que lidar com conexões IPv4 e IPv6
+    com um mínimo de soquetes, que requerem o uso de endereços IPv6 mapeados
+    para IPv4, especifique a opção <code>--enable-v4-mapped</code> do programa <program>
+    configure</program>.</p>
+
+    <p><code>--enable-v4-mapped</code> é o padrão para todas as plataformas exceto
+    para FreeBSD, NetBSD e OpenBSD, portanto esta é provavelmente a forma como o seu httpd foi
+    compilado.</p>
+
+    <p>Se o httpd tiver que lidar somente com conexões IPv4, independente do que
+    a sua plataforma e APR irão suportar, especifique um endereço IPv4 em todas as
+    diretivas <directive module="mpm_common">Listen</directive>, como nos
+    exemplos a seguir:</p>
+
+    <example>
+    <highlight language="config">
+Listen 0.0.0.0:80
+Listen 192.0.2.1:80
+    </highlight>
+    </example>
+
+    <p>Se a sua plataforma suporta e a intenção for lidar com conexões IPv4 e
+    IPv6 em soquetes separados (ou seja, desabilitar endereços mapeados
+    para IPv4), especifique a opção <code>--disable-v4-mapped</code> do programa <program>
+    configure</program>. <code>--disable-v4-mapped</code> é o padrão
+    no FreeBSD, NetBSD, e OpenBSD.</p>
+  </section>
+
+  <section id="protocol">
+    <title>Especificando o protocolo com Listen</title>
+    <p>O segundo argumento opcional <var>protocol</var> de
+       <directive module="mpm_common">Listen</directive>
+       não é requerido para a maioria das
+       configurações. Se não especificado, <code>https</code> é o padrão para
+       a porta 443 e <code>http</code> é o padrão para todas as outras portas. O
+       protocolo é usado para determinar que módulo deve lidar com uma requisição e
+       para aplicar otimizações de protocolo específicas com a diretiva
+       <directive module="core">AcceptFilter</directive>.</p>
+
+    <p>Somente é necessário definir o protocolo se o servidor estiver monitorando
+       portas não padrão. Por exemplo, para servir um site <code>https</code> na porta 8443:</p>
+
+    <example>
+    <highlight language="config">
+      Listen 192.170.2.1:8443 https
+    </highlight>
+    </example>
+  </section>
+
+  <section id="virtualhost">
+    <title>Como Isto Funciona com Hosts Virtuais</title>
+
+    <p>A diretiva <directive
+    module="mpm_common">Listen</directive> não implementa
+    Hosts Virtuais - ela apenas informa ao
+    servidor principal quais endereços e portas devem ser monitorados. Se nenhuma
+    diretiva <directive module="core" type="section">VirtualHost</directive>
+    for usada, o servidor se comportará
+    da mesma forma para todas as requisições aceitas. Entretanto,
+    <directive module="core" type="section">VirtualHost</directive>
+    pode ser usada para especificar um comportamento diferente
+    para um ou mais dos enredeços e portas. Para implementar um
+    Host Virtual, o servidor primeiro precisa ser informado para monitorar o
+    endereço e a porta que serão usados. Depois, uma
+    seção <directive module="core" type="section">VirtualHost</directive>
+    deve ser criada para o endereço e a porta especificados para definir o
+    comportamento desse host virtual. Observe que se a seção
+    <directive module="core" type="section">VirtualHost</directive>
+    estiver definida para um endereço e uma porta que o
+    servidor não estiver monitorando, o host virutal não poderá ser acessado.</p>
+  </section>
+</manualpage>
diff --git a/docs/manual/filter.xml.pt-br b/docs/manual/filter.xml.pt-br
new file mode 100644
index 0000000000..bf9bbb33a8
--- /dev/null
+++ b/docs/manual/filter.xml.pt-br
@@ -0,0 +1,178 @@
+<?xml version="1.0" encoding="UTF-8" ?>
+<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
+<?xml-stylesheet type="text/xsl" href="./style/manual.pt-br.xsl"?>
+<!-- English Revision: 1887636 -->
+<!-- Portuguese(BR) translation: leonardolara --><!-- Reviewed by: leonardolara -->
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements.  See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License.  You may obtain a copy of the License at
+
+     http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<manualpage metafile="filter.xml.meta">
+
+  <title>Filtros</title>
+
+  <summary>
+    <p>Este documento descreve o uso de filtros no Apache.</p>
+  </summary>
+
+  <section id="intro">
+    <title>Filtrando no Apache 2</title>
+    <related>
+      <modulelist>
+        <module>mod_filter</module>
+        <module>mod_deflate</module>
+        <module>mod_ext_filter</module>
+        <module>mod_include</module>
+        <module>mod_charset_lite</module>
+        <module>mod_reflector</module>
+        <module>mod_buffer</module>
+        <module>mod_data</module>
+        <module>mod_ratelimit</module>
+        <module>mod_reqtimeout</module>
+        <module>mod_request</module>
+        <module>mod_sed</module>
+        <module>mod_substitute</module>
+        <module>mod_xml2enc</module>
+        <module>mod_proxy_html</module>
+        <module>mod_policy</module>
+      </modulelist>
+      <directivelist>
+        <directive module="mod_filter">FilterChain</directive>
+        <directive module="mod_filter">FilterDeclare</directive>
+        <directive module="mod_filter">FilterProtocol</directive>
+        <directive module="mod_filter">FilterProvider</directive>
+        <directive module="mod_mime">AddInputFilter</directive>
+        <directive module="mod_mime">AddOutputFilter</directive>
+        <directive module="mod_mime">RemoveInputFilter</directive>
+        <directive module="mod_mime">RemoveOutputFilter</directive>
+        <directive module="mod_reflector">ReflectorHeader</directive>
+        <directive module="mod_ext_filter">ExtFilterDefine</directive>
+        <directive module="mod_ext_filter">ExtFilterOptions</directive>
+        <directive module="core">SetInputFilter</directive>
+        <directive module="core">SetOutputFilter</directive>
+      </directivelist>
+    </related>
+
+<p>A Cadeia de Filtros está disponível no Apache 2.0 e versões posteriores,
+e permite que as aplicações processem dados de entrada e saída
+de maneira altamente flexível e configurável, independentemente
+de onde os dados vêm. Podemos pré-processar dados de entrada
+e pós-processar dados de saída, conforme necessário. Isso é basicamente
+independente das fases tradicionais de processamento de requisições.</p>
+<p class="figure">
+<img src="images/filter_arch.pt-br.png" width="593" height="392" alt=
+"Filtros podem ser encadeados, em um Eixo de Dados ortogonal ao Processamento de Requisição"
+/>
+</p>
+<p>Alguns exemplos de filtragem na distribuição padrão do Apache são:</p>
+<ul>
+<li><module>mod_include</module>, implementa inclusões do lado do servidor.</li>
+<li><module>mod_ssl</module>, implementa criptografia SSL (https).</li>
+<li><module>mod_deflate</module>, implementa compressão/descompressão em tempo real.</li>
+<li><module>mod_charset_lite</module>, transcodifica entre diferentes conjuntos de caracteres.</li>
+<li><module>mod_ext_filter</module>, executa um programa externo como filtro.</li>
+</ul>
+<p>O Apache também usa vários filtros internamente para executar
+funções como fragmentação e manipulação de intervalos de bytes.</p>
+
+<p>Uma gama mais ampla de aplicações é implementada por módulos de
+filtro de terceiros. Alguns exemplos são:</p>
+
+<ul>
+<li>Processamento e reescrita de HTML e XML</li>
+<li>Transformações XSLT e XIncludes</li>
+<li>Suporte para namespace XML</li>
+<li>Processamento de envio de arquivos e decodificação de formulários HTML</li>
+<li>Processamento de imagem</li>
+<li>Proteção de aplicações vulneráveis, como scripts PHP</li>
+<li>Edição de busca e substituição de texto</li>
+</ul>
+</section>
+
+<section id="smart">
+<title>Filtragem Inteligente</title>
+<p class="figure">
+<img src="images/mod_filter_new.pt-br.png" width="423" height="331"
+alt="A filtragem inteligente aplica diferentes fornecedores de filtros de acordo com o estado do processamento da solicitação"/>
+</p>
+<p>O módulo <module>mod_filter</module>, incluído no Apache 2.1 e versões posteriores,
+permite que a cadeia de filtros seja configurada dinamicamente no momento da execução.
+Assim, por exemplo, você pode configurar um proxy para reescrever
+HTML com um filtro HTML e imagens JPEG com um filtro completamente
+separado, mesmo que o proxy não tenha nenhuma informação prévia
+sobre o que o servidor de origem enviará. Isso funciona usando um
+envoltório de filtros que direciona a requisição para diferentes provedores de acordo com
+o conteúdo real no momento da execução. Qualquer filtro pode ser
+inserido diretamente na cadeia e executado incondicionalmente ou
+usado como um provedor e inserido dinamicamente. Por exemplo,</p>
+<ul>
+<li>um filtro de processamento HTML só será executado se o conteúdo for
+text/html ou application/xhtml+xml</li>
+<li>um filtro de compressão só será executado se a entrada for de um tipo
+compressível e não estiver já comprimida.</li>
+<li>um filtro de conversão de conjunto de caracteres será inserido se um documento
+de texto ainda não estiver no conjunto de caracteres desejado.</li>
+</ul>
+</section>
+
+<section id="service">
+
+<title>Expondo Filtros como um Serviço HTTP</title>
+<p>Os filtros podem ser usados ​​para processar conteúdo originado do cliente, além
+de processar conteúdo originado no servidor usando o módulo
+<module>mod_reflector</module>.</p>
+
+<p>O módulo <module>mod_reflector</module> aceita requisições POST de clientes e reflete
+o conteúdo do corpo da requisição POST recebido de volta na resposta,
+passando pela pilha de filtros de saída no caminho de volta para o cliente.</p>
+
+<p>Essa técnica pode ser usada como uma alternativa a um serviço web executado dentro
+de uma pilha de servidor de aplicativos, onde um filtro de saída fornece a transformação
+necessária no corpo da requisição. Por exemplo, o módulo <module>mod_deflate</module>
+pode ser usado para fornecer um serviço de compressão geral, ou um filtro de
+transformação de imagem pode ser transformado em um serviço de transformação de imagem.</p>
+
+</section>
+
+<section id="using">
+<title>Usando Filtros</title>
+<p>Existem dois métodos de uso de filtros: Simples e Dinâmico.
+Em geral, deve ser usada apenas um ou outro; misturá-los pode
+ter consequências inesperadas (embora a filtragem de entrada simples
+possa ser misturada livremente com a filtragem de saída simples ou dinâmica).</p>
+<p>O Método Simples é a única maneira de configurar filtros de entrada e é
+suficiente para filtros de saída onde é necessária uma cadeia de filtros estática.
+As diretivas relevantes são
+    <directive module="core">SetInputFilter</directive>,
+    <directive module="core">SetOutputFilter</directive>,
+    <directive module="mod_mime">AddInputFilter</directive>,
+    <directive module="mod_mime">AddOutputFilter</directive>,
+    <directive module="mod_mime">RemoveInputFilter</directive> e
+    <directive module="mod_mime">RemoveOutputFilter</directive>.</p>
+
+<p>O Método Dinâmico permite a configuração estática e flexível/dinâmica
+dos filtros de saída, conforme discutido na página <module>mod_filter</module>.
+As diretivas relevantes são
+    <directive module="mod_filter">FilterChain</directive>,
+    <directive module="mod_filter">FilterDeclare</directive> e
+    <directive module="mod_filter">FilterProvider</directive>.</p>
+
+<p>Uma diretiva adicional, <directive
+module="mod_filter">AddOutputFilterByType</directive> também é suportada,
+porem obsoleta. Um a configuração dinâmica em seu lugar.</p>
+
+  </section>
+</manualpage>
diff --git a/docs/manual/howto/htaccess.xml.pt-br b/docs/manual/howto/htaccess.xml.pt-br
index f713dc203f..f418181f5d 100644
--- a/docs/manual/howto/htaccess.xml.pt-br
+++ b/docs/manual/howto/htaccess.xml.pt-br
@@ -1,7 +1,7 @@
 <?xml version="1.0" encoding="UTF-8" ?>
 <!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
 <?xml-stylesheet type="text/xsl" href="../style/manual.pt-br.xsl"?>
-<!-- English Revision: 1741841:1933862 (outdated) -->
+<!-- English Revision: 1933862 -->
 <!-- Portuguese(BR) translation: leonardolara --><!-- Reviewed by: leonardolara -->
 <!--
  Licensed to the Apache Software Foundation (ASF) under one or more
@@ -27,7 +27,8 @@
 
 <summary>
 <p>Arquivos <code>.htaccess</code> oferecem um meio de fazer alterações
- nas configurações por diretório.</p>
+nas configurações por diretório, sem modificar diretamente os arquivos
+de configuração principais do servidor.</p>
 </summary>
 
 <section id="related"><title>Arquivos .htaccess </title>
@@ -36,14 +37,15 @@
             <module>core</module>
             <module>mod_authn_file</module>
             <module>mod_authz_groupfile</module>
-            <module>mod_cgi</module>
             <module>mod_include</module>
             <module>mod_mime</module>
+            <module>mod_rewrite</module>
         </modulelist>
 
         <directivelist>
             <directive module="core">AccessFileName</directive>
             <directive module="core">AllowOverride</directive>
+            <directive module="core">AllowOverrideList</directive>
             <directive module="core">Options</directive>
             <directive module="mod_mime">AddHandler</directive>
             <directive module="core">SetHandler</directive>
@@ -56,23 +58,20 @@
 
     </related>
 
-    <note>O uso de arquivos <code>.htaccess</code> deve ser totalmente evitado se for possível o acesso ao
-    arquivo de configuração httpd principal. O uso de arquivos <code>.htaccess</code> deixa o Servidor Apache HTTP mais lento.
-    Qualquer diretiva que possa ser incluída em um <code>.htaccess</code> fica melhor se for incluída em um bloco <directive module="core">Directory</directive>, pois terá o mesmo efeito com um desempenho melhor.</note>
 </section>
 
 <section id="what">
     <title>O que eles são / Como usá-los</title>
 
-    <p>Os arquivos <code>.htaccess</code> (ou "arquivos de configuração distribuída")
+    <p>Os arquivos <code>.htaccess</code> (ou "arquivos de configuração distribuídos")
     oferecem um meio de fazer alterações nas configurações por diretório. Um
     arquivo, contendo uma ou mais diretivas de configurações, é colocado em um
-    diretório em particular e as diretivas se aplicam àquele diretório e a
+    diretório em particular e as diretivas se aplicam a este diretório e a
     todos os seus subdiretórios.</p>
 
-    <note><title>Nota:</title>
+    <note><title>Observação:</title>
       <p>Se o nome do arquivo precisar ser diferente de <code>.htaccess</code>,
-      deve ser usada a diretiva <directive
+      ele pode ser alterado através da diretiva <directive
       module="core">AccessFileName</directive>. Por exemplo,
       se a preferência for chamar o arquivo de <code>.config</code>, pode
       ser adicionada a seguinte linha ao arquivo de configuração do servidor:</p>
@@ -82,14 +81,17 @@ AccessFileName ".config"
       </highlight>
     </note>
 
-    <p>Em geral, arquivos <code>.htaccess</code> usam a mesma sintaxe
-    que os <a href="../configuring.html#syntax">arquivos de configuração
-    principal</a>. O que pode ser colocado nesses arquivos é determinado pela
-    diretiva <directive module="core">AllowOverride</directive>. Esta
-    diretiva especifica, em categorias, quais diretivas serão
-    honradas caso sejam encontradas em um arquivo <code>.htaccess</code>. Se uma
-    diretiva for permitida em um arquivo <code>.htaccess</code>, a
-    documentação para essa diretiva conterá uma seção Override,
+    <p>Diretivas nos arquivos <code>.htaccess</code> usam a mesma sintaxe
+    que os <a href="../configuring.html#syntax">arquivos principais
+    de configuração</a>. O que pode ser colocado nesses arquivos é determinado pelas
+    diretivas <directive module="core">AllowOverride</directive> E
+    <directive module="core">AllowOverrideList</directive>.
+    <directive module="core">AllowOverride</directive> especifica, em
+    categorias, quais diretivas serão honradas caso sejam encontradas em um
+    arquivo <code>.htaccess</code>, enquanto que <directive
+    module="core">AllowOverrideList</directive> nomeia diretivas
+    individuais a serem permitidas (consulte <a href="#when">abaixo</a>). Se uma diretiva
+    for permitida, a documentação para essa diretiva conterá uma seção Override,
     especificando que valor precisa estar em <directive
     module="core">AllowOverride</directive> para que essa diretiva
     seja permitida.</p>
@@ -102,62 +104,34 @@ AccessFileName ".config"
     <code>FileInfo</code>. Assim, deve-se ter pelo menos
     <code>AllowOverride FileInfo</code> para que essa diretiva seja
     honrada nos arquivos <code>.htaccess</code>.</p>
-
-    <example><title>Exemplo:</title>
-      <table>
-        <tr>
-          <td><a
-          href="../mod/directive-dict.html#Context">Contexto:</a></td>
-          <td>configuração do servidor, host virtual, diretório, .htaccess</td>
-        </tr>
-
-        <tr>
-          <td><a
-          href="../mod/directive-dict.html#Override">Override:</a></td>
-          <td>FileInfo</td>
-        </tr>
-      </table>
-    </example>
-
-    <p>Caso não haja certeza que se uma diretiva em particular é permitida em um
-    arquivo <code>.htaccess</code>, procure na documentação por essa
-    diretiva e verifique na linha Contexto a presença de ".htaccess".</p>
 </section>
 
 <section id="when"><title>Quando (não) usar arquivos .htaccess</title>
 
-    <p>Em geral, arquivos <code>.htaccess</code> só devem ser usados quando
-    não houver como acessar o arquivo de configuração principal do servidor. Existe,
-    por exemplo, um equívoco comum de que a autenticação de usuários
-    deve sempre ser feita em arquivos <code>.htaccess</code> e, mais recentemente,
-    outro equívoco de que as diretivas <module>mod_rewrite</module>
-    devem estar em arquivos <code>.htaccess</code>. Isso simplesmente não é verdade.
-    As configurações de autenticação de usuários podem ser colocadas na configuração principal do servidor,
-    e essa é, na verdade, a maneira preferida de fazer
-    as coisas. Da mesma forma, as diretivas <code>mod_rewrite</code> funcionam melhor,
-    em muitos aspectos, na configuração principal do servidor.</p>
+    <p>Se for possível o acesso ao arquivo de principal de configuração do servidor, todas
+    as configurações devem ser colocadas lá em vez de inseri-las em arquivos
+    <code>.htaccess</code>. Isto inclui autenticação de usuários,
+    regras do <module>mod_rewrite</module> e qualquer outra coisa que você tenha
+    tentação de colocar no <code>.htaccess</code>. Diretivas na configuração
+    principal são carregadas assim que o servidor inicia, e não a cada
+    requisição, e o <code>mod_rewrite</code> em particular funciona melhor
+    no contexto de configuração do servidor.</p>
 
     <p>Os arquivos <code>.htaccess</code> devem ser usados ​​nos casos em que os
     provedores de conteúdo precisam fazer alterações de configuração no servidor
-    por diretório, mas não têm acesso root ao sistema do servidor.
-    Caso o administrador do servidor não esteja disposto a fazer
+    por diretório, mas não têm acesso "root" ao sistema do servidor.
+    Isto é comum com ambientes de hospedagem gerenciados, hospedagem baseada
+    em painel de controle (como cPanel ou Plesk), e sistemas de gerenciamento de conteúdo onde
+    a aplicação envia um arquivo <code>.htaccess</code> como parte de sua
+    distribuição. Caso o administrador do servidor não esteja disposto a fazer
     alterações de configuração frequentes, pode ser desejável permitir que
     usuários individuais façam essas alterações em arquivos <code>.htaccess</code>
-    por conta própria. Isso é particularmente verdadeiro, por exemplo, em casos em que
-    ISPs hospedam vários sites de usuários em uma única máquina e desejam
-    que seus usuários possam alterar sua configuração.</p>
-
-    <p>No entanto, em geral, o uso de arquivos <code>.htaccess</code> deve ser
-    evitado sempre que possível. Qualquer configuração que se considere
-    colocar em um arquivo <code>.htaccess</code> pode ser feita com a mesma eficácia
-    em uma seção <directive module="core"
-    type="section">Directory</directive> no seu arquivo de configuração
-    principal do servidor.</p>
+    por conta própria.</p>
 
-    <p>Existem dois motivos principais para evitar o uso de arquivos
-    <code>.htaccess</code>.</p>
+    <p>Existem dois motivos principais para preferir o arquivo principal de configuração
+    no lugar do <code>.htaccess</code>: desempenho e segurança.</p>
 
-    <p>O primeiro desses motivos é o desempenho. Quando a diretiva <directive
+    <p>Desempenho: Quando a diretiva <directive
     module="core">AllowOverride</directive>
     está configurada para permitir o uso de arquivos <code>.htaccess</code>, o httpd
     procurará em todos os diretórios por arquivos <code>.htaccess</code>. Portanto,
@@ -166,57 +140,64 @@ AccessFileName ".config"
     arquivo <code>.htaccess</code> é carregado sempre que um documento é
     solicitado.</p>
 
-    <p>Observe ainda que o httpd deve procurar arquivos <code>.htaccess</code>
+    <p>Observe ainda que o httpd precisa procurar arquivos <code>.htaccess</code>
     em todos os diretórios de nível superior, a fim de ter um conjunto completo de
     diretivas que ele deve aplicar. (Consulte a seção sobre <a href="#how">como
     as diretivas são aplicadas</a>.) Assim, se um arquivo for solicitado de um
-    diretório <code>/www/htdocs/example</code>, o httpd deverá procurar os
+    diretório <code>/www/htdocs/example</code>, o httpd precisa procurar os
     seguintes arquivos:</p>
 
-    <example>
-      /.htaccess<br />
-      /www/.htaccess<br />
-      /www/htdocs/.htaccess<br />
-      /www/htdocs/example/.htaccess
-    </example>
+    <highlight language="config">
+/.htaccess
+/www/.htaccess
+/www/htdocs/.htaccess
+/www/htdocs/example/.htaccess
+    </highlight>
 
     <p>Assim, para cada acesso a um arquivo fora desse diretório, há 4
     acessos adicionais ao sistema de arquivos, mesmo que nenhum desses arquivos esteja
     presente. (Observe que isso só ocorreria se
-    os arquivos <code>.htaccess</code> estivessem habilitados para <code>/</code>, o que
+    os arquivos <code>.htaccess</code> estivessem habilitados para o diretório <code>/</code>, o que
     normalmente não acontece.)</p>
 
-    <p>No caso de diretivas <directive
-    module="mod_rewrite">RewriteRule</directive>, no contexto do
-    <code>.htaccess</code>, essas expressões regulares devem ser
-    recompiladas a cada requisição ao diretório, enquanto no contexto da configuração principal do
-    servidor, elas são compiladas uma vez e armazenadas em cache.
-    Além disso, as próprias regras são mais complexas, pois é preciso
-    contornar as restrições que acompanham o contexto por diretório
-    e o <code>mod_rewrite</code>. Consulte o <a
-    href="../rewrite/intro.html#htaccess">Guia de Reescrita</a> para obter mais
-    detalhes sobre este assunto.</p>
-
-    <p>A segunda consideração é de segurança. Esses arquivos permitem
-    que os usuários modifiquem a configuração do servidor, o que pode resultar em alterações sobre as quais
-    o administrador não tem controle. Considere cuidadosamente se deseja conceder
+    <p>Segurança: Você está permitindo
+    que usuários modifiquem a configuração do servidor, o que pode resultar em alterações sobre
+    as quais você não tem controle.Considere cuidadosamente se deseja conceder
     esse privilégio aos usuários. Observe também que conceder aos usuários menos
-    privilégios do que o necessário levará a solicitações adicionais de suporte técnico.
-    Certifique-se de informar claramente aos usuários qual o nível de
+    privilégios do que o necessário levará a solicitações adicionais de suporte
+    técnico. Certifique-se de informar claramente aos usuários qual o nível de
     privilégios que foi condedido a eles. Especificar exatamente o valor definido para
     <directive module="core">AllowOverride</directive> e direcioná-los
     para a documentação relevante evitará muita confusão
     posteriormente.</p>
 
+    <p>Se for necessário conceder acesso ao <code>.htaccess</code> porém limitando
+    a um conjunto específico de diretivas em vez de categorias inteiras, use a
+    diretiva <directive module="core">AllowOverrideList</directive>. Isso
+    permite nomear diretivas individuais que são permitidas, fornecendo
+    um controle mais fino que a <directive
+    module="core">AllowOverride</directive> sozinha:</p>
+
+    <highlight language="config">
+# Permite somente diretivas específicas, e não categorias inteiras
+AllowOverride None
+AllowOverrideList Redirect RedirectMatch RewriteEngine RewriteRule RewriteCond
+    </highlight>
+
+    <p>Com esta configuração, qualquer diretiva que não esteja explicitamente listada
+    causará um erro de servidor se encontrada em um arquivo <code>.htaccess</code>.
+    Isto é um meio termo útil entre o acesso total e nenhum
+    acesso.</p>
+
     <p>Observe que é completamente equivalente colocar um arquivo <code>.htaccess</code>
     em um diretório <code>/www/htdocs/example</code> contendo uma
     diretiva, e colocar essa mesma diretiva em uma seção Directory
-    <code>&lt;Directory "/www/htdocs/example"&gt;</code> na sua configuração principal do
+    <code>&lt;Directory "/www/htdocs/example"&gt;</code> na configuração principal do
     servidor:</p>
 
     <p>Arquivo <code>.htaccess</code> em <code>/www/htdocs/example</code>:</p>
 
-    <example><title>Contents of .htaccess file in
+    <example><title>Conteúdo do arquivo .htaccess em
     <code>/www/htdocs/example</code></title>
     <highlight language="config">
 AddType text/example ".exm"
@@ -232,11 +213,6 @@ AddType text/example ".exm"
     </highlight>
     </example>
 
-    <p>No entanto, colocar essa configuração no arquivo de configuração do servidor
-    resultará em uma perda de desempenho menor, pois a configuração é
-    carregada uma vez quando o httpd é iniciado, em vez de toda vez que um arquivo é
-    solicitado.</p>
-
     <p>O uso de arquivos <code>.htaccess</code> pode ser completamente desativado
     definindo a diretiva <directive module="core">AllowOverride</directive>
     como <code>none</code>:</p>
@@ -252,11 +228,11 @@ AllowOverride None
     são aplicadas ao diretório em que o arquivo <code>.htaccess</code>
     está localizado e a todos os seus subdiretórios. No entanto, é importante
     lembrar também que pode haver arquivos <code>.htaccess</code>
-    em diretórios acima na hierarquia. As diretivas são aplicadas na ordem em que
+    em diretórios acima na árvore. As diretivas são aplicadas na ordem em que
     são encontradas. Portanto, um arquivo <code>.htaccess</code> em um determinado
     diretório pode sobrescrever diretivas encontradas em arquivos <code>.htaccess</code>
-    localizados acima na hierarquia de diretórios. E estes, por sua vez, podem ter
-    sobrescrito diretivas encontradas ainda acima na hierarquia, ou no próprio arquivo de
+    localizados acima na árvore de diretórios. E estes, por sua vez, podem ter
+    sobrescrito diretivas encontradas ainda acima na árvore, ou no próprio arquivo de
     configuração principal do servidor.</p>
 
     <p>Exemplo:</p>
@@ -268,7 +244,7 @@ AllowOverride None
 Options +ExecCGI
     </highlight>
 
-    <p>(Observação: "<code>AllowOverride Options</code>" deve estar em vigor
+    <p>(Observação: "<code>AllowOverride Options</code>" precisa estar em vigor
     para permitir o uso da diretiva "<directive
     module="core">Options</directive>" em
     arquivos <code>.htaccess</code>.)</p>
@@ -286,8 +262,8 @@ Options Includes
     sobrescreve completamente qualquer configuração anterior que possa ter estado
     em vigor.</p>
 
-    <section id="merge">
-        <title>Mesclagem do .htaccess com os arquivos de configuração principais</title>
+    <section id="merge"><title>Mesclagem do .htaccess com os arquivos principais
+        de configuração</title>
 
         <p>Conforme discutido na documentação sobre <a
         href="../sections.html">Seções de Configuração</a>,
@@ -319,23 +295,13 @@ Options Includes
 
 <section id="auth"><title>Exemplo de Autenticação</title>
 
-    <p>Se você veio direto para esta parte do documento para descobrir como
-    fazer a autenticação, é importante observar uma coisa. Existe um
-    equívoco comum de que é necessário usar
-    arquivos <code>.htaccess</code> para implementar a autenticação por senha.
-    Isso não é verdade. Colocar as diretivas de autenticação
-    em uma seção <directive module="core" type="section">Directory</directive>
-    no arquivo de configuração principal do servidor é a maneira preferida
-    de implementar isso, e os arquivos <code>.htaccess</code> devem ser usados ​​somente
-    se você não tiver acesso ao arquivo de configuração principal do servidor. Veja <a
-    href="#when">acima</a> uma discussão sobre quando se deve e quando não se deve
-    usar arquivos <code>.htaccess</code>.</p>
-
-    <p>Dito isso, se você ainda acredita que precisa usar um arquivo
-    <code>.htaccess</code>, a configuração a seguir provavelmente
-    funcionará para você.</p>
+    <p>Como em qualquer caso de uso de <code>.htaccess</code>, inserir estas diretivas em
+    um bloco <directive module="core" type="section">Directory</directive> é
+    preferido quando se tem acesso à configuração principal (consulte
+    <a href="#when">above</a>). O exemplo s seguir mostra o método
+    <code>.htaccess</code>:</p>
 
-    <p>Conteúdo de um arquivo <code>.htaccess</code>:</p>
+    <p>Conteúdo de <code>.htaccess</code>:</p>
 
     <highlight language="config">
 AuthType Basic
@@ -381,14 +347,14 @@ AddHandler server-parsed shtml
     Considere os seguintes exemplos:</p>
 
     <highlight language="config">
-    # No arquivo httpd.conf
-    RewriteRule "^/imagens/(.+)\.jpg" "/imagens/$1.png"
+# No arquivo httpd.conf
+RewriteRule "^/imagens/(.+)\.jpg" "/imagens/$1.png"
 
-    # No arquivo .htaccess do diretório raiz
-    RewriteRule "^imagens/(.+)\.jpg" "imagens/$1.png"
+# No arquivo .htaccess do diretório raiz
+RewriteRule "^imagens/(.+)\.jpg" "imagens/$1.png"
 
-    # No arquivo .htaccess do diretório imagens/
-    RewriteRule "^(.+)\.jpg" "$1.png"
+# No arquivo .htaccess do diretório imagens/
+RewriteRule "^(.+)\.jpg" "$1.png"
     </highlight>
 
     <p>Em um arquivo <code>.htaccess</code> no diretório de documentos, a barra inicial
@@ -398,14 +364,24 @@ AddHandler server-parsed shtml
     dele. Portanto, a expressão regular precisa omitir essa parte
     também.</p>
 
-    <p>Consulte a documentação do <a href="../rewrite/">mod_rewrite</a> para
+    <p>Observe também que no contexto do <code>.htaccess</code>, expressões regulares são
+    recompiladas a cada requisição, enquanto que na configuração principal do servidor elas
+    são compiladas apenas uma vez e armazenadas em cache.</p>
+
+    <p>Consulte a <a href="../rewrite/">documentação do mod_rewrite</a> para
     obter mais detalhes sobre como usar o <code>mod_rewrite</code>.</p>
 
 </section>
 
 <section id="cgi"><title>Exemplo de CGI</title>
 
-    <p>Por fim, pode ser necessário usar um arquivo <code>.htaccess</code> para permitir
+    <note>Scripts CGI são um mecanismo legado para conteúdo dinâmico. Para novos
+    desenvolvimentos, considere o uso de <module>mod_proxy_fcgi</module> com um
+    servidor de aplicação FastCGI ou um manipulador específico para algum framework. A
+    informação abaixo permanece útil para ambientes que ainda dependem de
+    CGI tradicional.</note>
+
+    <p>Pode ser necessário usar um arquivo <code>.htaccess</code> para permitir
     a execução de programas CGI em um diretório específico. Isso pode ser
     implementado com a seguinte configuração:</p>
 
@@ -442,19 +418,26 @@ SetHandler cgi-script
     module="core">AllowOverride</directive> não está
     configurada de forma que suas diretivas de configuração sejam respeitadas.
     Certifique-se de que não exista um <code>AllowOverride None</code> em vigor
-    para o escopo do arquivo em questão. Um bom teste para isso é colocar lixo
-    no seu arquivo <code>.htaccess</code> e recarregar a página. Se um erro do servidor não for
-    gerado, então quase certamente existe <code>AllowOverride
-    None</code> em vigor.</p>
+    para o escopo do arquivo em questão. Um bom teste para isso é colocar uma
+    palavra sem sentido no seu arquivo <code>.htaccess</code> e recarregar a
+    página:</p>
+
+    <highlight language="config">
+TestMe
+    </highlight>
+
+    <p>Se um erro do servidor (HTTP 500) não
+    for gerado, é quase certeza que <code>AllowOverride
+    None</code> esteja em vigor.</p>
 
     <p>Se, por outro lado, erros do servidor estiverem sendo gerados ao tentar
     acessar documentos, verifique o registro de erros do httpd. Ele provavelmente informará
     que a diretiva usada no arquivo <code>.htaccess</code> não é
     permitida.</p>
 
-    <example>
-    [Fri Sep 17 18:43:16 2010] [alert] [client 192.168.200.51] /var/www/html/.htaccess: DirectoryIndex not allowed here
-    </example>
+    <highlight language="config">
+[Tue May 06 09:12:31.528374 2025] [core:alert] [pid 12345] [client 192.168.1.50:54321] /var/www/html/.htaccess: DirectoryIndex not allowed here
+    </highlight>
 
     <p>Isso indicará que foi usada uma diretiva que
     nunca é permitida em arquivos <code>.htaccess</code>, ou que simplesmente
@@ -466,11 +449,11 @@ SetHandler cgi-script
     <p>Alternativamente, pode aparecer um erro de sintaxe no
     uso da própria diretiva.</p>
 
-    <example>
-    [Sat Aug 09 16:22:34 2008] [alert] [client 192.168.200.51] /var/www/html/.htaccess: RewriteCond: bad flag delimiters
-    </example>
+    <highlight language="config">
+[Tue May 06 09:14:02.946218 2025] [core:alert] [pid 12345] [client 192.168.1.50:54321] /var/www/html/.htaccess: RewriteCond: bad flag delimiters
+    </highlight>
 
-    <p>Nesse caso, a mensagem de erro deve ser específica para o
+    <p>Neste caso, a mensagem de erro deve ser específica para o
     erro de sintaxe cometido.</p>
 
 </section>
diff --git a/docs/manual/images/filter_arch.pt-br.png b/docs/manual/images/filter_arch.pt-br.png
new file mode 100644
index 0000000000..37aa926d7b
Binary files /dev/null and b/docs/manual/images/filter_arch.pt-br.png differ
diff --git a/docs/manual/images/mod_filter_new.pt-br.png b/docs/manual/images/mod_filter_new.pt-br.png
new file mode 100644
index 0000000000..48e2d8b164
Binary files /dev/null and b/docs/manual/images/mod_filter_new.pt-br.png differ