O mod_include oferece um método de processamento de arquivos antes do envio de dados para o cliente. Normalmente, o mod_include é usado para a inclusão de arquivos em um documento. Esses arquivos, por sua vez, são analisados como HTML antes de chegar até o cliente. É por isso que é chamado de "server-side includes" (SSI).

Com os SSIs, comandos especiais são executados no servidor, acionados por comentários SGML formatados. Esses comandos SGML possuem a seguinte sintaxe:

<!--#element attribute=value -->
        

Para obter uma lista de valores de elementos e atributos, consulte a documentação mod_include em http://httpd.apache.org/docs-2.0/mod/mod_include.html.

Para usar o mod_include no SUSE Linux, adicione include a APACHE_MODULES em /etc/sysconfig/apache2 ou use o YaST de acordo com a descrição em Módulos.

	Dica
Use a diretiva XBitHack (http://httpd.apache.org/docs-2.0/mod/mod_include.html#xbithack) para instruir o Apache a analisar arquivos com o conjunto de bits executar das diretivas SSI. Isso significa que, em vez de ter de mudar a extensão de um arquivo para marcá-lo como portador de elementos SSI (.shtml no exemplo acima), você pode usar um arquivo .html normal e executar chmod +x myfile.html.

O mod_cgi permite ao Apache entregar conteúdos criados por programas ou scripts de CGI externos ("Interface de Gateway Comum"). Ele atua como uma instância entre uma linguagem de programação disponível na máquina física e o servidor Web do Apache. Teoricamente, os scripts CGI podem ser escritos em qualquer linguagem de programação. Em geral, são usadas linguagens como Perl ou C. mod_cgi é a forma mais comum de incluir conteúdo dinâmico em um site.

A programação CGI difere da programação "normal" no sentido de que os programas e scripts CGI precisam ser capazes de gerar um tipo MIME Content-type: text/html para produzir em HTML.

#!/path/to/perl
print "Content-type: text/html\n\n";
print "Hello, World.";
            

A diferença entre os módulos especificamente atrelados a uma linguagem de programação (como mod_php5) e mod_cgi reside na possibilidade de se combinar mod_cgi com mod_suexec (consulte Seção 46.5.2.1, “Executando as CGIs como um usuário diferente com mod_suexec ”). Essa combinação permite que os scripts CGI sejam executados com um ID de usuário. Em geral, os scripts que usam o mod_cgi isoladamente ou o mod_php5 são executados com o ID do usuário Apache (padrão no SUSE Linux: wwwrun). Os módulos projetados para uma linguagem de programação (como mod_php5 ou mod_ruby) embutem um interpretador persistente no Apache para executar scripts com o ID de usuário do Apache.

Em decorrência disso, as CGIs com mod_suexec ajudam com a clareza administrativa já que os processos CGI podem ser designados a usuários específicos em vez do próprio servidor Web. Além disso, essa combinação propicia uma melhor segurança do sistema de arquivos: o script herda somente os direitos do sistema de arquivos do usuário. No caso contrário dos módulos, o script recebe as permissões de arquivo do usuário do servidor Web, que podem levar à visibilidade não desejada de dados no sistema de arquivos.

Os CGIs são encerrados quando a solicitação de um cliente ao servidor Web termina. Isso significa que as CGIs não são persistentes e liberam todos os recursos ocupados após o encerramento. Trata-se de uma vantagem, sobretudo em caso de programação incorreta. Com os módulos, os efeitos dos erros de programação podem se acumular, pois o interpretador é persistente. Isso pode acarretar uma falha na liberação dos recursos, como conexões de bancos de dados, e pode exigir que o Apache seja reiniciado.

Para usar o mod_cgi no SUSE Linux, adicione cgi a APACHE_MODULES em /etc/sysconfig/apache2 ou use o YaST de acordo com a descrição em Módulos. O diretório padrão das CGIs no SUSE Linux é /srv/www/cgi-bin/.

Se estiver fazendo a edição manual do arquivo de configuração do Apache, use esse exemplo como uma diretriz para a configuração de mod_cgi.

# Global Environment
LoadModule cgi_module /path/to/mod_cgi.so

# Servidor principal e/ou do host virtual e/ou
# Diretório e/ou contexto .htaccess
AddHandler cgi-script .cgi .pl

# Contexto do servidor principal e/ou do host virtual
ScriptAlias /cgi-bin/ /srv/www/cgi-bin/

# Outra opção é permitir explicitamente os scripts CGI em um diretório
# Contexto do servidor principal e/ou host virtual 
<Diretório /srv/www/some/dir>
    Opções +ExecCGI 
<Diretório>
            

Em combinação com mod_cgi (Seção 46.5.1.2, “Interface de Gateway Comum: mod_cgi ”), o mod_suexec permite que os scripts CGI sejam executados como um usuário e grupo especificados. O programa suEXEC, localizado em /usr/sbin/suexec2, é usado para essa finalidade. Trata-se de um agrupador chamado pelo Apache toda vez que um script ou programa CGI é executado. Em seguida, o agrupador e o programa fazem a designação do usuário e ID de grupo configurados. Em decorrência disso, ele é executado como o usuário ou grupo configurado.

Embora essa abordagem reduza bastante o risco de segurança associado aos scripts CGI gerados pelo usuário, ela também suscita algumas considerações importantes:

Em caso de erros causados por mod_suexec, consulte o arquivo de registro suexec em /var/log/apache2/suexec.log.

Para usar o mod_suexec no SUSE Linux, adicione suexec a APACHE_MODULES em /etc/sysconfig/apache2 ou use o YaST de acordo com a descrição em Módulos. Lembre-se que é necessário o mod_cgi para executar o suexec.

A melhor forma de usar o mod_suexec é aplicando-o em um ambiente de host virtual, descrito em Seção 46.4, “Hosts virtuais”. Para especificar um determinado usuário e grupo como o que irá executar os scripts CGI, use a seguinte sintaxe no arquivo portador das declarações do host virtual (o padrão no SUSE Linux é /etc/apache2/vhosts.d/*):

<VirtualHost 192.168.0>
# ...
ScriptAlias /cgi-bin/ /srv/www/vhosts/www.example.com/cgi-bin/
SuexecUserGroup tux users
# ...
</VirtualHost>
            

A sintaxe SuexecUserGroup nome de usuário grupo deste exemplo designa a todos os scripts contidos em /srv/www/vhosts/www.example.com/cgi-bin/ o ID de usuário de tux e o ID de grupo dos usuários.

mod_ssl oferece uma criptografia forte usando protocolos de secure sockets layer (SSL) e segurança de camada de transporte (TLS) para a comunicação HTTP entre um cliente e o servidor Web. Para isso, o servidor envia um certificado SSL contendo informações que comprovam a validade da identidade do servidor antes que solicitações a um URL sejam respondidas. Por sua vez, isso garante que o servidor é o único ponto de terminação correto para essa comunicação. Além disso, o certificado gera uma conexão criptografada entre o cliente e o servidor capaz de transmitir informações sem o risco de exposição de conteúdo confidencial em texto simples. O efeito mais visível do uso de mod_ssl com o Apache é que os URLs aparecem com o prefixo https:// em vez do prefixo http://.

A porta padrão das solicitações SSL e TLS no servidor Web é a 443. Não há conflito entre uma recepção “normal” do Apache na porta 80 e uma recepção habilitada por SSL/TLS do Apache na porta 443. Na verdade, HTTP e HTTPS podem ser executados com a mesma instância do Apache. Geralmente, um host virtual (consulte Seção 46.4, “Hosts virtuais”) é usado para encaminhar solicitações à porta 80 e à porta 443 para servidores virtuais separados.

Hosts virtuais baseados em nome e SSL

É impossível executar vários hosts virtuais habilitados por SSL em um servidor dotado de apenas um endereço IP. Os usuários que se conectarem a uma configuração como essa receberão uma mensagem de aviso informando que o certificado não corresponde ao nome do servidor toda vez que eles visitam o URL. Um endereço IP ou porta separado é necessário para todo domínio habilitado por SSL para efetivar a comunicação baseada em um certificado SSL válido. Apesar da mensagem de aviso, ainda assim você obterá o mesmo nível de criptografia que teria em qualquer site SSL válido. Isso significa que, contanto que a mensagem de aviso seja aceitável, a comunicação entre o servidor Web e o cliente continua segura. O conceito de conhecimento único da identidade do servidor, que é garantido por um certificado SSL válido, é perdido.

Para ativar o mod_ssl no SUSE Linux, adicione ssl a APACHE_MODULES em /etc/sysconfig/apache2 ou use o YaST de acordo com a descrição em Módulos. Além disso, o servidor Web precisa estar configurado para fazer a recepção na porta 443 de padrão HTTPS. Isso pode ser feito manualmente em /etc/apache2/listen.conf ou em YaST por meio da entrada de menu ‘Recepção’ (consulte Seleção de dispositivos de rede).

Para criar um certificado SSL de teste, digite cd /usr/share/doc/packages/apache2; ./certificate.sh como a raiz. Siga as instruções na tela para compor o certificado SSL. Os arquivos de certificado resultantes são abrigados nos diretórios /etc/apache2/ssl*.

Um certificado “real” com validade global pode ser obtido com fornecedores como Thawte (http://www.thawte.com/ ou Verisign (www.verisign.com).

Se estiver fazendo a edição manual do arquivo de configuração do Apache, use esse exemplo como uma diretriz para a configuração de mod_ssl.

# Ambiente Global
# faça a recepção na porta SSL padrão 
Recepção 443 
# carregue o módulo somente se rcapache2 start-ssl tiver sido emitido
<IfDefine SSL>
LoadModule ssl_module /path/to/mod_ssl.so
</IfDefine>

# Contexto do servidor principal
# incluir configuração SSL global (em todo o servidor)
# que não seja especifica a algum host virtual
# somente se ssl_module tiver sido carregado
<IfModule mod_ssl.c>
Include /etc/apache2/ssl-global.conf
</IfModule>
            

	Dica
Não se esqueça de abrir o firewall do Apache habilitado por SSL na porta 443. Para fazer isso por meio do YaST, vá até ‘Segurança e Usuários’+‘Firewall’+‘Serviços Permitidos’. Em seguida, adicione ‘Servidor HTTPS’ à lista de ‘Serviços Permitidos’.

O mod_perl embute um interpretador Perl persistente no Apache. Isso evita a sobrecarga causada por um mod_cgi que chama um executável externo em cada solicitação a um CGI. O mod_perl também permite controlar vários aspectos da funcionalidade do Apache com a ajuda da linguagem de programação Perl.

Para usar o mod_perl no SUSE Linux, instale o RPM apache2-mod_perl e ative o módulo através do YaST (Módulos) ou manualmente no /etc/sysconfig/apache2. Após a instalação e ativação, um arquivo de configuração separado, mod_perl.conf, é colocado em /etc/apache2/conf.d/. Adicionalmente, o script de inicialização mod_perl é instalado como mod_perl-startup.pl. Para obter mais informações sobre como usar o módulo, consulte a documentação disponível no site mod_perl na Web (http://perl.apache.org/).

O PHP é uma linguagem de programação conhecida direcionada originalmente ao uso na Web. Ele existe em duas versões: PHP4 e PHP5. Enquanto o PHP4 representa o conceito e a abordagem clássicos do PHP, o PHP5 introduziu novas possibilidades de programação orientada a objetos junto com vários outros recursos avançados. O mod_php4 e o mod_php5 estão disponíveis no SUSE Linux. Eles embutem o interpretador PHP no Apache como um módulo persistente.

Para usar o mod_php4 ou mod_php5 no SUSE Linux, instale o respectivo RPM (apache2-mod_php4, apache2-mod_php5) e ative o módulo por meio do YaST (Módulos) ou manualmente, no /etc/sysconfig/apache2.

Após a instalação e a ativação, um arquivo de configuração separado para o respectivo módulo (php4.conf ouphp5.conf) é colocado em /etc/apache2/conf.d/. O site do PHP na Web (http://www.php.net) é um recurso excelente para usar o Apache junto com o PHP.

O mod_python embute o interpretador Python no Apache. Python é uma linguagem de programação orientada a objetos com uma sintaxe muito clara e legível. Um recurso incomum, porém conveniente, é que a estrutura do programa depende da indentação do código-fonte e não de elementos de demarcação regulares como begin e end.

Para usar o mod_python no SUSE Linux, instale o RPM apache2-mod_python e ative o módulo por meio do YaST (Módulos) ou manualmente, no /etc/sysconfig/apache2. Para obter mais informações sobre como usar o módulo, consulte a documentação disponível no site mod_python na Web (http://www.modpython.org/).

O mod_ruby embute o interpretador Ruby no servidor Web Apache, permitindo que os scripts CGI Ruby sejam executados de forma nativa. Ruby é uma linguagem de programação de alto nível orientada a objetos relativamente nova que lembra certos aspectos do Perl e Python. Como o Python, ela possui uma sintaxe limpa e transparente. Por outro lado, o Ruby adotou abreviações (como $.r para o número da última linha lida no arquivo de entrada) que são apreciadas por alguns programadores, mas não por outros. O conceito básico do Ruby é muito parecido com o do Smalltalk.

Para usar o mod_ruby no SUSE Linux, instale o RPM apache2-mod_ruby e ative o módulo por meio do YaST (Módulos) ou manualmente, no /etc/sysconfig/apache2. Para obter mais informações sobre como usar o módulo, consulte a documentação disponível no site mod_ruby na Web (http://www.modruby.net/en/index.rbx).

O mod_dav oferece a funcionalidade WebDAV (Web-Based Distributed Authoring and Versioning) para o Apache. WebDAV é uma extensão do protocolo HTTP que permite que os usuários editem e gerenciem arquivos em colaboração em servidores remotos. Os recursos do WebDAV são semelhantes aos do FTP, com a diferença principal que o HTTP é usado como o protocolo subjacente para acesso ao servidor. Na verdade, o mod_dav faz com que um servidor Web Apache seja um sistema avançado de arquivos remotos.

É uma boa prática, se não for necessário, limitar o acesso aos diretórios disponíveis por meio do WebDAV. As precauções mínimas a serem tomadas são configurar a autenticação básica HTTP para o recurso WebDAV e possuir condições Limit dentro de uma diretiva Location.

Para acessar um recurso WebDAV, o software compatível com WebDAV precisa estar presente no cliente. O SUSE Linux já é fornecido com recursos WebDAV: Konqueror com o prefixo webdav:// ou webdavs:// (para WebDAV em conexões SSL) pode ser usado para conectar-se a um sistema de arquivos WebDAV do Apache.

O mod_dav requer o módulo mod_dav_fs, que oferece acesso ao sistema de arquivos real para o WebDAV. Para usar o mod_dav no SUSE Linux, ative o módulo por meio do YaST (Módulos) ou manualmente, no /etc/sysconfig/apache2. Faça o mesmo para o mod_dav_fs. Para obter mais informações sobre como usar o módulo, consulte a documentação disponível no site mod_dav na Web (http://httpd.apache.org/docs-2.0/mod/mod_dav.html).

O padrão do mod_userdir no SUSE Linux é oferecer o conteúdo de cada pasta ~/public_html do usuário como páginas da Web públicas. O URL para acessar essas páginas é http://www.exemplo.com/~nome_de_usuário/.

	Dica
O mod_userdir no SUSE Linux proíbe o acesso a quaisquer diretórios do diretório pessoal do usuário root por questões de segurança. Você também pode permitir especificamente que somente certos usuários tenham home pages públicas usando: # Main server context UserDir disabled UserDir enabled tux wilber

Para usar o mod_userdir no SUSE Linux, ative o módulo por meio do YaST (Módulos) ou manualmente, no /etc/sysconfig/apache2. Para obter mais informações sobre como usar o módulo, consulte a documentação disponível no site mod_userdir na Web (http://httpd.apache.org/docs-2.0/mod/mod_userdir.html).

O mod_rewrite é geralmente conhecido como “o canivete suíço da manipulação de URL”. Ele regrava URLs solicitados dinamicamente com base em um conjunto de regras especificado. O resultado geralmente é semelhante a http://www.exemplo.com/2/1/de para http://www.exemplo.com/display.php?cat=2&article=1&lang=de.

O URL Rewriting Guide (Guia de regravação de URL) explica as vantagens e desvantagens do módulo avançado e complexo:

“Com o mod_rewrite, ou você dá um tiro no próprio pé na primeira vez e nunca o usa novamente ou o adora para o resto de sua vida devido a sua capacidade.”

Os conjuntos RewriteRule podem ser definidos em todos os contextos de configuração: para o servidor principal, para hosts virtuais, para diretórios e para arquivos .htaccess. Um bom ponto de partida para a regravação de URLs com o mod_rewrite é o URL Rewriting Guide (Guia de regravação de URL) em http://httpd.apache.org/docs-2.0/misc/rewriteguide.html.

Para usar o mod_rewrite no SUSE Linux, ative o módulo por meio do YaST (Módulos) ou manualmente, no /etc/sysconfig/apache2.