IIS 7.5 retornando 404 para nomes de host desconhecidos

Question

Isso simplesmente não parece correto para mim, então estou procurando alguém para me dizer como eu configurei mal o IIS ... A configuração é IIS7.5 (2008R2), sem o SP1.

Eu tenho o IIS 7.5 configurado com vários sites. Todos os sites têm nomes de host definidos nas ligações, não há nenhum site com um nome de host. No entanto, se eu solicitar um nome de host desconhecido do servidor IIS (tecnicamente Microsoft-HTTPAPI / 2.0), retorne um erro 404, não um erro 400. Eu esperaria um 400 (ou algum outro grande erro) em vez de um humilde 404.

Isso causa um problema quando eu tenho o nginx na frente de vários IISs e quero parar um site para que o nginx o tire da rotação. Como o IIS ainda retorna um 404 para a solicitação, mesmo quando não há um site ativo para esse nome, o nginx não sabe que o servidor está morto.

NB: O IIS retorna o 404, independentemente de haver um servidor, mas está parado ou não há servidor.

Pensamentos? Soluções?

- Informações adicionais: OK, adicionei um site em uma porta diferente de 80 (5000) e, em seguida, em uma conexão para essa porta solicitei um site que não existe e recebo o erro esperado 400 (Invalid nome de anfitrião). Assim, enquanto o IIS não está escutando conexões genéricas (sem nome de host) na porta 80, parece que algo está. Alguma idéia de como fazer HTTPSys despejar a lista do que está escutando?

    

Answer 1

Isso é por design. Uma reserva de URL não é o mesmo que um registro de URL, que acontece dinamicamente quando um aplicativo se registra com HTTP.SYS para ouvir. No caso de uma reserva de URL, o HTTP.SYS não sabe se o URL em uma determinada reserva está simplesmente indisponível temporariamente ou não existe. Tudo o que se pode saber nesse caso é que existe uma correspondência de nome de host válida (devido a seu caractere curinga strong / fraco), mas o caminho da URL não corresponde a nenhum dos ouvintes registrados no momento.

Se você deseja uma resposta 400 ou 503, não use nenhuma URL Reservation nem use Reservas de URL explícitas que não incluam curingas. Em suma, se você configurar o HTTP.SYS de modo que ele possa corresponder ao prefixo da URL para qualquer Reservation (incluindo os dinâmicos criados via Registration), ele entregará a solicitação ao aplicativo de escuta (se as correspondências restantes), ou retorne um 404 se não puder encontrar um ouvinte registrado ativo.

Outra solução que pode ser mais simples é usar o próprio serviço IIS para gerenciar o envio de um 503. Para fazer isso, não pare o site, mas sim interrompa o Pool de Aplicativos associado a ele. Isso fará com que uma correspondência totalmente qualificada ocorra no HTTP.SYS (mesmo com as Reservas de URL do wlidcard), mas resultará em um 503 porque não há AppPool para entregar a solicitação.

    

Answer 2

Existe um módulo HTTP ativo instalado na instância do IIS que você não conhece, que captura todas as solicitações?

Ou você esqueceu que para parar o site padrão (que vem com uma instalação padrão do IIS) ativo / em execução, então é uma ligação vazia.

A ligação padrão do site padrão está em branco, o que significa que aceita todos os cabeçalhos de host HTTP.

    

Answer 3

OK, depois de várias horas "agradáveis" com o suporte técnico da MS, não estamos de acordo se isso é um bug ou não, mas estamos de acordo que o problema decorre da presença do " link "que é adicionado pelo WCF.

Como uma "solução alternativa", se você adicionar um urlacl mais específico ao seu site no formato de: netsh http adicionar urlacl url = link usuario = redeservice listen = sim delegado = sim

então você receberá um 503, não um 404. Eu mantenho que isso é um "bug", MS está "checando" (sem prender a respiração).

Para quem acertar isso, o problema # é REG: 112060473529066.

    

Answer 4

OK, descobri (mas acho que é um bug, é preciso relatar é para o MS mais tarde). Se eu olhar para as URLACLs listadas para HTTPSys usando "netsh http show urlacl", vejo um registro para " link ". Isso não deve coincidir com o pedido que estou enviando, mas parece ser a correspondência. De acordo com a documentação do UrlPrefix, isso não seria igual, mas, de acordo com meus testes, não.

Quando criei um novo site na porta 5000, não havia registro para que o temporary_listen_address funcionasse como eu esperava. Com dois sites (diferentes cabeçalhos de host) em execução na porta 5000, uma solicitação para um site interrompido retorna erro 400. No entanto, se eu registrar um urlacl (netsh http adicionar urlacl) de " link " e solicitar algo que não corresponde ao prefixo url, recebo um 404. Remova o registro e recebo um 400 novamente.

Eu gosto de HTTPSys em geral, mas é muito complicado quando você curte isso. Vai atualizar a resposta w / MS mais tarde. Eu não vejo um lugar em connect.microsoft.com para denunciá-lo, então tenho que ligar.