--- /dev/null
+<?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>
--- /dev/null
+<?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>
<?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
<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>
<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>
</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>
</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>
<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,
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><Directory "/www/htdocs/example"></code> na sua configuração principal do
+ <code><Directory "/www/htdocs/example"></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"
</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>
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>
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>
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>,
<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
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
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>
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
<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>
projects / thirdparty / apache / httpd.git / commitdiff
