No início deste ano, planejei reescrever meu programa de blog com base na estrutura expressa usando o Node.js e dizer adeus ao ASP.NET a partir de agora. No entanto, o VPS que eu uso atualmente é o sistema Windows Server e o IIS Server. Se Express e Iis ouvem o Port 80, haverá conflitos óbvios. Felizmente, existe uma extensão chamada iisNode que hospeda programas Node.js para o IIS. Além disso, após a hospedagem, também significa que várias funções no IIS podem ser usadas (gerenciamento de processos, compactação GZIP, log, cache, controle de permissão, ligação de nomes de domínio etc.).
Para usar o iisNode, você precisa instalar:
1.node.js
2. Módulo de reescrita de URL IIS
3.IisNode
Após a instalação, você ainda segue as operações usuais para criar um site no gerente do IIS e apontar para o diretório do programa Express. A chave é adicionar um arquivo web.config:
A cópia do código é a seguinte:
<figuration>
<System.WebServer>
<levadores>
<add name = "iisnode" path = "bin /www" verb = "*" modules = "iisNode" ResourceType = "não especificado" requereAccess = "script" />
</manipuladores>
<Rewrite>
<sules>
<regra name = "all">
<corresponda a url = " /*" />
<Action type = "rewrite" url = "bin /www" />
</regra>
</regras>
</crite>
</system.webserver>
</figuration>
Esse conteúdo também pode ser configurado através da interface visual do IIS Manager. Significa aproximadamente reescrever todas as solicitações para bin/www e executar o bin/www usando a extensão iisNode. No entanto, depois de abrir o site, uma mensagem de erro é exibida:
A cópia do código é a seguinte:
O módulo de filtro de solicitação está configurado para rejeitar os caminhos no URL que contém a seção Hiddensement
No começo, senti que não estava claro sobre isso, mas mais tarde percebi de repente que o diretório de bin no ASP.NET é um diretório especial que não pode ser acessado. Reescreva a solicitação para bin/www, que atinge esta regra. Então, basta alterar o nome do diretório, por exemplo, alterar o bin para ser lançado (não é uma boa prática, vamos falar sobre isso mais tarde), e o web.config também precisa ser ajustado de acordo:
A cópia do código é a seguinte:
<figuration>
<System.WebServer>
<levadores>
<add name = "iisNode" path = "launch /www" verb = "*" modules = "iisNode" ResourceType = "não especificado" requereAccess = "script" />
</manipuladores>
<Rewrite>
<sules>
<regra name = "all">
<corresponda a url = " /*" />
<Action type = "rewrite" url = "lançamento /www" />
</regra>
</regras>
</crite>
</system.webserver>
</figuration>
Depois de reiniciar o site no gerente do IIS, acessando -o novamente, ele finalmente começou a correr, não foi fácil! Mas eu ainda estava muito feliz.
Durante o processo de teste da função do programa, verificou -se que o IP obtido estava vazio. Na estrutura expressa, o IP é obtido através do req.ip, que por sua vez obtém o valor do REMOTE_ADDR do cabeçalho da solicitação. Através de um código de teste simples, verificou -se que o valor do REMOTE_ADDR também está vazio. É óbvio que essa informação do cabeçalho é perdida durante o processo do IIS ao Node.JS. Depois do Google, descobri que o IisNode tem esse problema. A solução oficial é usar o x-forword-for, mas encontrei outra solução.
Há uma configuração no web.config (antes de adicioná -lo a </system.webserver>) que pode reter REMOTE_ADDR:
A cópia do código é a seguinte:
<iisnode promoveservervars = "remote_addr" />
De acordo com as instruções, o REMOTE_ADDR reservado será renomeado para x-iisnode-remote_addr, para que você precise substituir o valor do req.ip uma vez e adicionar uma função de middleware ao app.js de Express:
A cópia do código é a seguinte:
App.use (function (req, res, próximo) {
req.ip = req.headers ['x-iisnode-remote_addr'];
próximo();
});
No entanto, após esse ajuste, o IP obtido ainda está vazio, o que inevitavelmente faz as pessoas se perguntarem se a atribuição do Req.IP falhou. Olhando para o código -fonte do Express, você descobrirá que o req.ip é definido através do Definy Getter; portanto, para substituí -lo, você deve definir novamente:
A cópia do código é a seguinte:
App.use (function (req, res, próximo) {
Object.DefineProperty (req, 'ip', {
get: function () {return this.headers ['x-iisnode-remote_addr']; }
});
próximo();
});
Esse problema finalmente foi resolvido, mas esse não é um bom método. Será problemático se o Express definir o req.ip apenas para leitura no futuro.
Continue testando e encontre outro problema. Normalmente, a função de upload de arquivos no fundo do blog passa o arquivo para o diretório público/upload, mas, de fato, a pasta pública/upload é gerada no diretório de lançamento (ou seja, o diretório BIN original). De fato, o motivo é que o arquivo www como a entrada do programa está no diretório de lançamento, para que o diretório de lançamento se torne o diretório de execução do aplicativo. Minha solução é alterar o nome do diretório de lançamento de volta ao bin, criar um lançamento.js no diretório raiz para ligar para bin/www:
A cópia do código é a seguinte:
#!/usr/bin/Env nó
requer ('./ bin/www');
Em seguida, altere a entrada do programa para Launch.js:
A cópia do código é a seguinte:
<figuration>
<System.WebServer>
<levadores>
<add name = "iisnode" path = "launc (js" verb = "*" modules = "iisNode" ResourceType = "não especificado" requereAccess = "script" />
</manipuladores>
<Rewrite>
<sules>
<regra name = "all">
<corresponda a url = " /*" />
<Action type = "rewrite" url = "launch.js" />
</regra>
</regras>
</crite>
<iisnode promoveservervars = "remote_addr" />
</system.webserver>
</figuration>
Obviamente, o IisNode não é um produto maduro e, é claro, o Node.js ainda não é (nem o 1.0), tudo precisa de mais exploração e melhoria.