Eu estou usando o IIS7.5, .net 4.0. Eu estou trabalhando localmente.

Eu instalei o Application Request Routing, o Web Farm Framework, o WebDeploy e o UrlRewrite para configurar um proxy reverso. Isso funciona bem na maior parte.

Eu tenho dois sites:

DefaultWebSite (porta 80, pool de aplicativos: Pool de aplicativos padrão (.net 4)) eDestino (porta 8085, pool de aplicativos: TargetAppPool (minha identidade, .net 4)).

Eu tenho uma regra de reescrita no DefaultWebSite (criado como direcionado emIIS.net) que redireciona todo o tráfego localhost (porta 80) paralocalhost: 8085 tal como detalhado no link acima. Isso funciona bem para a maioria dos tipos de documento (.aspx, .xap, .htm, .ico), mas uma solicitação para MyService.svc falha. Ele retorna um 404.

Para ser claro:

Quando eu colarlocalhost: 8085 / MyService.svc em um navegador, recebo a página do WCF solicitada.

Quando eu colarlocalhost / MyService.svc em um navegador eu recebo um 404.

Quando eu colarlocalhost: 8085 / MyIcon.ico em um navegador eu recebo o recurso solicitado.

Quando eu colarlocalhost / MyIcon.ico em um navegador eu recebo o recurso solicitado.

.svc é o único tipo de documento que eu encontrei que retorna um 404.

Eu tenho duas informações que podem ser relevantes.

Pools de aplicativos. Quando altero o pool de aplicativos do DefaultWebSite para TargetAppPool, o 404 se torna um 500 ("Falha ao mapear o caminho" / ""). Todas as outras solicitações são bem-sucedidas quando essa alteração é feita. Não tenho certeza se isso é relevante ou não.

Rastreamento de solicitação de falha (FREB). Eu encontrei uma página (http://blogs.msdn.com/b/asiatech/archive/2011/08/25/return-404-4-not-found-when-url-rewrite.aspx) que detalha as etapas em um log do FREB quando uma reescrita de URL é mais bem-sucedida do que a minha (falha mais tarde). Eu não fui capaz de descobrir como gerar um log de FREB para uma reescrita bem sucedida (se é que isso é possível), então eu só posso comparar o meu log de FREB com aquele daquele blog. Eu posso ver que o passo 21 (URL_CHANGED) no meu log do FREB, mas não 22 (URL_REWRITE_END). Eu não tenho experiência suficiente com esses registros para notar algo mais significativo do que isso (sugestões bem-vindas).

Minha principal questão é: alguém sabe por que apenas URLs solicitando recursos .svc não estão sendo reescritos?

Uma questão secundária é: alguém sabe como gerar um log FREB para uma solicitação bem-sucedida (se é possível)?

obrigado

Atualizar:

Eu mudei a arquitetura para tentar obter mais informações.

Eu movi o site da Target para um PC diferente no qual eu instalei o Microsoft Network Monitor para capturar o tráfego de entrada.

Antes de alterar a regra de regravação de URL para apontar para este novo site, obtive a resposta correta quando solicitei ao MyService.svc no novo PC. Bem.

Assim que alterei a regra de reescrita para encaminhar a solicitação para o novo site da Target, ela responde como antes (404). Eu fiz pedidos POST e GET. Não há sinal de nenhuma das solicitações no log do Network Monitor (todas as outras chamadas -200, 404 ou de outra forma - aparecem neste log).

Isso me leva a pensar que há algo incompatível com solicitações de url-reescreve e * .svc. Eu tentei fazer um pedido para MyService.asmx (tendo criado este arquivo) e ele retornou corretamente uma página, por isso é limitado a * .svc. Alguma ideia?