Modernizando o Classic ASP: Um guia prático para hospedar o AxonASP usando o IIS

Sejamos honestos: quando a maioria dos desenvolvedores ouve falar em "Classic ASP", logo imaginam servidores Windows legados, registros complexos de objetos COM e uma arquitetura profundamente atrelada ao asp.dll e ao processo de trabalho do IIS (w3wp.exe).

Mas o código em si — muitas vezes milhares de linhas de lógica de negócios crítica escritas em VBScript ou JavaScript no lado do servidor — ainda cumpre exatamente o seu papel. O problema não é necessariamente a linguagem; é a arquitetura de hospedagem monolítica e envelhecida.

É aqui que o AxonASP muda o jogo. Construído em Go, ele desvincula completamente o ASP do sistema operacional Windows, executando o código nativamente e reduzindo o uso de memória em modo ocioso para cerca de 18MB.

No entanto, mudar para esse motor exige uma virada de chave fundamental na forma como você pensa sobre a hospedagem das suas aplicações.

A mudança de paradigma: Arquitetura centrada na aplicação

Em relação à arquitetura de hospedagem: o AxonASP não é um substituto direto para o IIS; ele é um ambiente de execução (runtime) de Classic ASP. Ele opera em uma arquitetura moderna e centrada na aplicação — estruturalmente idêntica à forma como aplicações modernas em .NET Core ou Docker são implantadas.

Isso significa que todas as suas configurações existentes do IIS continuam totalmente válidas. Para orquestrar o AxonASP adequadamente dentro do IIS, você deve usar o módulo HttpPlatformHandler v1.2+. Você pode ler mais sobre essa configuração no manual oficial aqui:

• Manual do AxonASP - Suporte ao IIS
• Manual do AxonASP - Migrando do IIS & Classic ASP para o AxonASP

Por exemplo, no arquivo axonasp.toml, você pode definir o diretório raiz para coincidir com o diretório padrão do seu site no IIS. Isso permite que você sirva seus arquivos estáticos (CSS, JS, imagens) nativamente pelo IIS, enquanto o AxonASP cuida da lógica da aplicação e das requisições dinâmicas .asp.

A ideia principal é universalizar e implementar práticas modernas de administração para o ASP, permitindo que ele rode em qualquer plataforma ou servidor. Dessa forma, se um site sair do controle ou esgotar a memória, ele não derrubará as outras aplicações nem o servidor principal, porque cada aplicação roda sua própria instância isolada e distinta do axonasp-http.exe.

Essa estrutura também permite que você rode o ASP dentro de containers Docker, reduzindo significativamente os custos associados a servidores Windows. Pode parecer um pouco complexo no início, mas com certeza vale a pena migrar para essa abordagem — ela é mais segura, altamente distribuível, mais barata e, no fim das contas, mais fácil de gerenciar.

---

Passo a passo: Implementando o AxonASP no IIS

Como o IIS gerencia o FastCGI via named pipes do Windows (que são incompatíveis com os protocolos FastCGI padrão baseados em TCP), não podemos simplesmente plugar o AxonASP como um módulo legado. Em vez disso, o IIS agirá como um proxy reverso, ficando na borda da sua rede (Portas 80/443) e encaminhando as requisições dinâmicas para instâncias isoladas do AxonASP que rodam em portas locais de loopback (ex: 8801, 8802).

Veja como configurar:

1. Pré-requisitos

Você precisará do IIS HttpPlatformHandler v1.2+. Este é o exato mesmo módulo que a Microsoft recomenda para gerenciar aplicações Python ou Java atrás do IIS. Ele cuida do gerenciamento de processos, atribui portas dinamicamente e garante que o executável do AxonASP continue rodando.

2. Diretórios e permissões

Digamos que o seu site esteja localizado em C:\Sites\App1\.
Dentro desta pasta, você deve ter:

• O binário axonasp-http.exe.
• O arquivo de configuração axonasp.toml.
• O script de inicialização iis-http.cmd (fornecido com o AxonASP).
• A sua pasta www contendo os arquivos .asp.

Passo crucial: A identidade de usuário do IIS (geralmente IIS_IUSRS ou a ApplicationPoolIdentity específica) deve ter permissões de leitura e escrita nesta pasta. O AxonASP precisa gravar em seu diretório temporário (temp) e executar os binários. Se faltarem permissões, o IIS falhará silenciosamente e retornará um erro 500 Internal Server Error.

3. A configuração do web.config

Insira um arquivo web.config na raiz do seu site no IIS. Isso instrui o IIS a interromper a tentativa de processar o código nativamente e, em vez disso, passá-lo para o processo do AxonASP.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <handlers>
            <add name="httpPlatformHandler" path="*" verb="*" modules="httpPlatformHandler" resourceType="Unspecified" />
        </handlers>

        <httpPlatform processPath="C:\Sites\App1\iis-http.cmd"
                      arguments="--server.server_port %HTTP_PLATFORM_PORT%"
                      stdoutLogEnabled="true"
                      stdoutLogFile="C:\Sites\App1\temp\axonasp.log"
                      startupTimeLimit="5"
                      processesPerApplication="1">
            <environmentVariables>
                <environmentVariable name="SERVER_PORT" value="%HTTP_PLATFORM_PORT%" />
            </environmentVariables>
        </httpPlatform>
    </system.webServer>
</configuration>

Entendendo a mecânica da configuração

Existem dois detalhes críticos no XML acima que ditam como a sua aplicação vai se comportar:

• %HTTP_PLATFORM_PORT%: Você não precisa atribuir manualmente a porta 8801 para o Site A e 8802 para o Site B. O IIS gera uma porta disponível de forma dinâmica, injeta-a na variável de ambiente, inicializa o processo do AxonASP e direciona o tráfego para ela automaticamente.
• processesPerApplication="1": Não altere este valor para um número maior. O Classic ASP depende muito de estado em memória (variáveis de Session e o ciclo de vida do global.asa). Se o IIS gerar múltiplos processos de trabalho (worker processes) para um único site, as sessões dos usuários ficarão fragmentadas entre eles. O AxonASP gerencia a concorrência internamente por meio de goroutines; ele precisa de apenas um processo do sistema operacional por site.

Por que esta arquitetura é o futuro do ASP

Ao desacoplar o motor de execução do sistema operacional, você não fica mais preso à infraestrutura legada do Windows.

1. A era pós-COM: O AxonASP intercepta chamadas de Server.CreateObject("ProgID") nativamente. Em vez de depender do frágil Registro do Windows para carregar uma DLL antiga, o AxonASP mapeia essa chamada para um código GoLang moderno de alta velocidade pré-compilado dentro da VM.
2. Infraestrutura como código: Suas regras de roteamento, configurações e variáveis de ambiente agora são arquivos de texto simples (.toml e .config) que acompanham o repositório da sua aplicação.
3. O horizonte com Docker: Depois de migrar com sucesso um site para este modelo de proxy no IIS, migrar esse mesmo site para um container Docker em Linux atrás do Nginx ou Caddy exigirá praticamente zero alterações na lógica da aplicação.

O Classic ASP pode ter décadas de idade, mas com um motor construído em Go e uma arquitetura que reflete os microsserviços modernos, não há razão para que ele não possa rodar na vanguarda da infraestrutura web atual.