mod_gzip - servindo conteúdo comprimido pelo servidor web Apache

Autor: Michael Schröpl

Na verdade, realizar a instalação não é difícil, mas encontrar o método que melhor se adapta às necessidades da sua instalação do Apache pode levar algum tempo.

Portanto, é altamente recomendável que você leia este capítulo completamente e esteja ciente dos prós e contras das diferentes opções antes de selecionar o método de operação e realizar a instalação.

O documento em questão cobre especialmente o modelo de processamento interno do mod_gzip como um módulo Apache e pode, portanto, fornecer informações que podem ser úteis para entender o método de avaliação do mod_gzip para diretivas de configuração.

Fundamentos

Introdução

O servidor web Apache suporta dois métodos diferentes de integrar um módulo em seu código de programa:

integração estática e
integração dinâmica.

Dependendo do conceito de operação usado para seu servidor Apache e dos requisitos dados

um desses dois métodos de operação para o mod_gzip deve ser selecionado e
o conjunto de arquivos necessários para este método deve ser baixado.

Integração estática de um módulo Apache

Integração estática significa que o módulo se torna uma parte permanente do binário de programa httpd que implementa o servidor Apache.

Para isso, o código-fonte do servidor Apache deve ser

estendido pelo código-fonte deste módulo e então
compilado como um todo usando um compilador C.

Normalmente, cada administrador pode querer usar um conjunto diferente de recursos para seu servidor Apache adaptado às suas próprias necessidades; portanto, não parece viável fornecer arquivos de programa prontos para execução em uma multitude de plataformas para download.

Integração dinâmica de um módulo Apache

Integração dinâmica significa que o módulo pode ser carregado a partir de um arquivo de módulo separado como objeto compartilhado ao iniciar o processo Apache.

Para isso

o arquivo de objeto compartilhado deste módulo para a plataforma alvo necessária deve ser - ou adquirido ou gerado e
instalado no diretório correspondente do Apache e
o arquivo de configuração do Apache deve ser estendido por uma diretiva para carregar este módulo.

A estrutura do código-fonte do módulo mod_gzip

A maioria dos módulos Apache consiste em um único arquivo de código-fonte. Este arquivo pode ser compilado invocando o programa apxs (com os valores de parâmetro correspondentes); para a instalação do objeto compartilhado criado dessa forma, seria necessária mais uma invocação do apxs (com valores de parâmetro diferentes).

A partir da versão 1.3.26.1a, o código-fonte do mod_gzip é dividido em três arquivos separados:

mod_gzip.c (cerca de 8000 linhas) contém todas as funções necessárias para implementar a lógica de processamento do módulo Apache mod_gzip.
Este arquivo depende muito da interface do módulo da versão 1.3 do Apache (que não mudou por muitos anos).
mod_gzip_debug.c (cerca de 500 linhas) contém funções que são necessárias apenas para tarefas de depuração para o desenvolvedor; parte dessas funções não está nem mesmo contida em um mod_gzip compilado ‘da maneira normal’ (dependendo dos valores das diretivas do compilador do tipo -D para definir constantes simbólicas).
mod_gzip_compress.c (cerca de 3000 linhas) contém a implementação da função de compressão gzip de Kevin Kiley, aquela que ‘realmente faz o trabalho’.
Esta parte não depende de nenhuma versão específica do Apache e (do ponto de vista puramente técnico) pode ser usada por outras ferramentas de compressão também (como mod_deflate que atualmente usa o ‘zlib’ para compressão).

Essa estrutura do código-fonte torna a manutenção do mod_gzip um pouco mais fácil - e a instalação um pouco mais complicada (já que agora vários arquivos de origem precisam ser compilados em vez de apenas um). Portanto, o mod_gzip agora fornece Makefile s para simplificar esse processo de instalação.

Download

Dependendo de qual dos conceitos de operação mencionados acima deve ser executado, diferentes arquivos (adequados para o respectivo propósito de uso) devem ser utilizados.

No momento da redação, os seguintes arquivos estão disponíveis para cada versão do mod_gzip na página de download do projeto mod_gzip:

| mod_gzip- versão .tgz: | um arquivo tar comprimido com gzip do produto mod_gzip, incluindo - o código-fonte do módulo (na linguagem de programação C),

vários Makefile s (para compilar o código-fonte),
um Change-Log (como documentação curta das mudanças mais importantes para todas as versões do programa) e
a documentação em questão. | | ApacheModuleGzip.dll.zip: | um arquivo ZIP contendo o arquivo de objeto compartilhado do mod_gzip para a plataforma Windows. | | mod_gzip- versão -FreeBSD-4.6-i386.so.gz: | um arquivo comprimido com gzip contendo o arquivo de objeto compartilhado do mod_gzip para a plataforma FreeBSD-UNIX 4.6. | | mod_gzip.so.gz: | um arquivo comprimido com gzip contendo o arquivo de objeto compartilhado do mod_gzip para a plataforma Solaris 2.7. |

Se o mod_gzip deve ser executado com integração dinâmica em alguma outra plataforma, então o arquivo de módulo compartilhado para essa plataforma deve ser criado pelo administrador.

Integração estática do mod_gzip

A compilação normal do servidor web Apache

O procedimento para instalar o servidor web Apache em uma máquina UNIX documentado pelo Apache Group é assim (na versão curta):

baixe o arquivo com o código-fonte do Apache da WWW
descompacte o arquivo
navegue até o diretório criado pela operação anterior
leia e entenda o arquivo INSTALL
inicie o script de shell ./configure com os valores de parâmetro apropriados (isso causará a criação de arquivos Makefile em um grande número de subdiretórios)
make install (isso causará a compilação e instalação do servidor Apache, incluindo sua documentação online)

Se o servidor web Apache foi criado dessa forma, então os módulos enviados normalmente se tornam partes estáticas do arquivo de programa httpd no diretório do programa Apache - a menos que você tenha especificado algo diferente nos parâmetros da chamada configure.

(A chamada real do configure pode se tornar muito extensa, dependendo do grau de desvio dos valores de parâmetro padrão. Eu recomendo armazenar essa chamada em um pequeno script de shell para documentar o tipo de instalação processada, a propósito.)

A integração do mod_gzip no código-fonte do Apache

O código-fonte dos módulos oficiais do Apache está contido no subdiretório src/modules do arquivo tar descompactado do software Apache.

Para que o mod_gzip seja tratado como um módulo padrão do Apache por esse mecanismo, as seguintes preparações são necessárias:

Descompacte e extraia o conteúdo do arquivo de download contendo o código-fonte do mod_gzip (o que criará um diretório mod_gzip- número da versão),
Crie um diretório src/modules/gzip dentro da árvore de diretórios do código-fonte do Apache
Copie todos os arquivos com as extensões .c*, .h e .tmpl para este novo diretório gzip.

Como próximo passo, você estende a chamada configure pelo parâmetro –activate-module=src/modules/gzip/mod_gzip.c. Agora o script configure encontrará o código-fonte do mod_gzip e criará um Makefile adequado a partir do arquivo enviado Makefile.tmpl - registrado pelas mensagens

 + módulo gzip ativado (modules/gzip/mod_gzip.c)

Criando Makefile em src/modules/gzip

este último assim como para os próprios módulos do Apache. (O Makefile enviado com o mod_gzip não é adequado para este tipo de instalação - este é apenas para a criação de um arquivo de objeto compartilhado.)

Agora a instalação do Apache funcionará como de costume - e o mod_gzip será tratado como um módulo normal do Apache.

Mas o configure sabe que um módulo integrado via o parâmetro –activate-module é um módulo de terceiros que pode ter requisitos específicos, e assim carregará o mod_gzip automaticamente no topo da pilha de módulos para que ele tenha acesso à solicitação HTTP recebida antes de todos os outros módulos - que é exatamente o que o mod_gzip precisa urgentemente.

Em algumas plataformas, o configure do Apache não parece definir automaticamente o valor da variável de ambiente $(LIBEXT) para o valor adequado de .a. Nesse caso, a compilação do mod_gzip falhará. A razão exata para esse comportamento é desconhecida até agora; como solução alternativa, você pode substituir a linha

LIB=libgzip.$(LIBEXT)

por

LIB=libgzip.a

dentro do arquivo enviado Makefile.tmpl, ou seja, insira o valor adequado manualmente.

Certifique-se de usar um editor que não expanda caracteres de tabulação em espaços para essa tarefa!

(Para ser testado: O que acontece ao integrar mais de um módulo de terceiros com –activate-module? A ordem dos valores de parâmetro é relevante nesse caso?)

Verifique se o mod_gzip foi integrado corretamente

Para verificar se o mod_gzip realmente foi integrado ao código do programa Apache conforme solicitado, o servidor Apache fornece o comando httpd -l. Isso exibirá uma lista de todos os módulos integrados (na ordem em que serão carregados); mod_gzip.c deve ser a última entrada exibida lá.

Integração dinâmica do mod_gzip

O conceito de módulos Apache carregáveis

O servidor web Apache suporta o conceito de módulos carregáveis.

Quase cada módulo Apache pode ser

compilado como um objeto compartilhado e então
carregado dinamicamente no espaço de endereço do Apache no início do servidor Apache (usando as diretivas de configuração correspondentes).

O manuseio de módulos carregáveis requer conhecimento adicional sobre a configuração do Apache (porque a ordem em que esses módulos são carregados pode ser significativa para seu funcionamento), mas permite alterações no intervalo de código do servidor Apache sem ter que recompilar seu código-fonte.

Em plataformas como Windows (onde não muitos administradores do Apache têm um ambiente de desenvolvimento C à mão para compilar e vincular o código do Apache), o uso de módulos carregáveis pode muitas vezes ser a única possibilidade de ampliar o escopo funcional do servidor Apache.

A documentação do Apache 1.3 fornece os seguintes artigos sobre este tópico:

Suporte a Objetos Compartilhados Dinâmicos (DSO) - a descrição do conceito correspondente para o servidor web Apache
Módulo mod_so - a descrição do módulo Apache para carregar outros módulos e as diretivas de configuração necessárias

Diretiva para carregar mod_gzip

Para adicionar dinamicamente o objeto compartilhado mod_gzip ao código do Apache, uma das seguintes diretivas de configuração é necessária:

# ---------------------------------------------------------------------  
# carregar um DLL / Windows:  
  LoadModule gzip_module modules/ApacheModuleGzip.dll  
# ---------------------------------------------------------------------  
# carregar um DSO / UNIX:  
  LoadModule gzip_module modules/mod_gzip.so**  
# ---------------------------------------------------------------------  
# (nenhum dos dois se o módulo estiver integrado estaticamente)  
# ---------------------------------------------------------------------

O nome do arquivo real pode ser selecionado livremente - ele apenas precisa corresponder ao nome do arquivo efetivamente usado. Por outro lado, esse nome pode depender da plataforma do sistema operacional e até mesmo do método de compilação usado para este módulo - nesse caso, ou a diretiva mostrada acima deve ser adaptada ou o arquivo deve ser renomeado de acordo.

O manuseio de módulos pelo Apache 1.3

O servidor Apache pode carregar dinamicamente qualquer número de módulos. Ao fazer isso, as diretivas LoadModule correspondentes são processadas na ordem de sua ocorrência dentro do arquivo de configuração.

Mas os módulos são carregados em uma pilha dentro da memória de trabalho: O módulo que foi carregado por último será o primeiro a ter acesso ao tratamento da solicitação HTTP correspondente ao servidor web Apache - e pode então decidir se considera-se responsável por tratar essa solicitação ou não.

Somente um de todos os módulos em questão pode ser responsável por tratar uma solicitação no Apache 1.3 - módulos subsequentes não serão nem mesmo questionados.

A integração do mod_gzip na avaliação de uma solicitação do Apache

Portanto, para poder processar a saída de módulos arbitrários, o mod_gzip tem que fazer algo que na verdade contradiz a arquitetura do Apache 1.3: Ele tem que ‘tratar’ uma solicitação, mas posteriormente revogar a responsabilidade por tratar essa solicitação. Somente por esse procedimento o módulo que é efetivamente responsável por tratar a solicitação pode ainda ser ativado pelo servidor Apache.

Nesta primeira fase, o ‘tratamento’ dessa solicitação pelo mod_gzip não significa comprimir o conteúdo da página a ser servida - porque esse conteúdo ainda não existe, ele ainda precisa ser gerado por outro módulo! Em vez disso, neste momento, o mod_gzip apenas se prepara para ser questionado novamente se deseja fazer algo após a criação do conteúdo da página. Somente nesta segunda fase de sua ativação (onde o conteúdo da resposta HTTP já está disponível então) o mod_gzip pode realizar sua tarefa essencial, que é comprimir o conteúdo de um pacote de resposta HTTP (e a modificação de certos cabeçalhos HTTP).

Esse ‘registro’ para posterior pós-processamento da resposta HTTP realizado pelo mod_gzip é necessário apenas se o mod_gzip não puder já determinar neste estágio que definitivamente não estará interessado em processar o conteúdo da resposta de qualquer maneira.

Assim, nesta primeira fase, o mod_gzip já realiza uma parte da avaliação das diretivas de filtro especificadas na configuração do Apache: Ele verifica aquelas regras onde pode fazer isso com base apenas na descrição da solicitação (ou seja, o conteúdo dos cabeçalhos HTTP correspondentes). Isso se aplica às regras mod_gzip_item_include / mod_gzip_item_exclude do tipo

reqheader (conteúdo dos cabeçalhos de solicitação HTTP da solicitação),
url (URL do recurso HTTP solicitado),
file (nome do arquivo do arquivo afetado por essa solicitação, após a avaliação de todas as traduções Alias etc.) e
handler (nome do manipulador responsável por avaliar essa solicitação, de acordo com a configuração do Apache).

Se a avaliação dessas regras de filtro já provar que o resultado dessa solicitação não deve ser comprimido, ou seja, se

pelo menos uma regra excluir for satisfeita ou
nenhuma das regras incluir for satisfeita ou
se qualquer outra condição para realizar a compressão não for satisfeita (por exemplo, neste estágio já pode ser verificado se o cliente autorizou o fornecimento de dados comprimidos enviando o cabeçalho HTTP Accept-Encoding: gzip)

então não é necessário que o mod_gzip verifique as regras restantes após a criação do conteúdo da resposta - então isso não acontecerá, porque o mod_gzip se lembra do resultado da primeira fase de avaliação para cada solicitação e termina a segunda fase imediatamente nesse caso.

Caso contrário, na segunda fase de sua operação, o mod_gzip verifica as regras de filtro restantes que podem ser avaliadas apenas com base no conteúdo real do pacote de resposta gerado:

rspheader (conteúdo dos cabeçalhos de resposta HTTP) assim como
mime (tipo de conteúdo HTTP do resultado).

Além disso, algumas outras condições são testadas agora, como o tamanho do pacote de resposta (diretivas mod_gzip_minimum_file_size rsp. mod_gzip_maximum_file_size).

E somente se todas essas verificações resultarem em um resultado positivo, a compressão do pacote de resposta será realmente realizada.

A posição do mod_gzip dentro da sequência de carregamento de todos os módulos Apache

Para poder realizar todas as tarefas descritas acima, o módulo mod_gzip deve ter acesso ao tratamento da solicitação HTTP antes de cada outro módulo Apache cuja saída ele deve tratar. Devido à ordem invertida de acesso ao tratamento de uma solicitação para todos os módulos Apache, o mod_gzip deve ser carregado como o último de todos os módulos Apache.

Para a integração estática, essa ordem de módulos é definida pelo ‘plano’ do programa httpd durante a compilação do código-fonte do Apache. O procedimento para compilar o código-fonte do Apache enviado pelo Apache Group, ativado pelo script de shell configure, conhece todas as dependências entre os módulos enviados (e garante uma ordem correspondente desses módulos), mas não os requisitos de módulos de terceiros como o mod_gzip que são integrados ao processo de compilação pelo parâmetro –add-module= arquivo. Para permitir um máximo de influência a esses módulos de terceiros, tais módulos são carregados como últimos módulos na pilha de módulos.

Assim, se o mod_gzip deve ser integrado a um servidor Apache como o único módulo de terceiros, então o configure automaticamente faz a coisa certa. No caso de usar mais de um módulo de terceiros, o administrador é responsável por ordenar esses módulos (talvez pela ordem de seus valores –add-module=? Eu ainda não testei isso).

Compilando o mod_gzip usando apxs

A função da utilidade de compilação do Apache apxs

Se um servidor Apache é operado para suportar a integração dinâmica de módulos (ou seja, usa o módulo mod_so), então um programa utilitário chamado apxs será gerado no diretório bin do Apache durante a instalação do Apache.

Este programa permite ao seu usuário compilar o código-fonte de um módulo Apache (usando um compilador C) e criar um correspondente arquivo de objeto compartilhado sem exigir que o código-fonte completo dos servidores Apache esteja disponível: apxs conhece todas as interfaces de programa Apache necessárias e fornece ao compilador C as informações necessárias.

Criando um objeto compartilhado para mod_gzip usando make

Para poupar o usuário de descobrir como exatamente o mod_gzip deve ser compilado e instalado completamente ao usar apxs, um arquivo chamado Makefile é fornecido dentro do arquivo de código-fonte.

Usando este Makefile reduz o procedimento de instalação aos seguintes passos:

Extraia os arquivos do arquivo de código-fonte do mod_gzip baixado para um diretório (novo, temporário) de sua escolha e mude sua posição de diretório atual para lá.
Descubra o nome do caminho do programa apxs da sua instalação do Apache.
Realize a compilação executando o comando make APXS=*seu_caminho_apxs* Isso criará o arquivo de objeto compartilhado mod_gzip.so dentro do diretório atual.
(Este passo da sequência de operação pode ser omitido, pois será coberto pelo passo subsequente.)
Realize a instalação executando o comando make install APXS=*seu_caminho_apxs* Isso não apenas copiará o arquivo de objeto compartilhado para o diretório correspondente da instalação do Apache, mas também estenderá automaticamente o arquivo de configuração do Apache httpd.conf pelas diretivas necessárias LoadModule e AddModule também … se você não gosta que programas externos reescrevam seus preciosos arquivos de configuração, pode preferir realizar este passo final manualmente, ou pelo menos fazer um backup da sua configuração do Apache primeiro.

Além desses passos necessários, o Makefile suporta os seguintes comandos (que podem ser mais do interesse dos desenvolvedores):

make clean remove todos os arquivos de módulo objeto criados dos arquivos de código-fonte do mod_gzip do diretório atual (ou seja, todos os arquivos com o padrão de nome *.o).
make clean adicionalmente remove o arquivo de objeto compartilhado criado mod_gzip.so também.

Localização original deste documento:

http://www.schroepl.net/projekte/mod_gzip/install.htm

mod_gzip - servindo conteúdo comprimido pelo servidor web Apache - Página 5