Używam IIS7.5, .net 4.0. Pracuję lokalnie.

Zainstalowałem aplikację Application Request Routing, Web Farm Framework, WebDeploy i UrlRewrite, aby skonfigurować odwrotne proxy. W większości przypadków działa to dobrze.

Mam dwie strony internetowe:

DefaultWebSite (port 80, pula aplikacji: domyślna pula aplikacji (.net 4)) iCel (port 8085, pula aplikacji: TargetAppPool (moja tożsamość, .net 4)).

Mam regułę przepisywania w DefaultWebSite (utworzoną zgodnie z poleceniami naIIS.net), który przekierowuje cały ruch localhost (port 80) nalocalhost: 8085 dokładnie tak, jak opisano w powyższym linku. Działa to dobrze dla większości typów dokumentów (.aspx, .xap, .htm, .ico), ale żądanie do MyService.svc nie powiedzie się. Zwraca 404.

Aby być jasnym:

Kiedy wklejamlocalhost: 8085 / MyService.svc do przeglądarki Dostaję żądaną stronę WCF.

Kiedy wklejamlocalhost / MyService.svc do przeglądarki dostaję 404.

Kiedy wklejamlocalhost: 8085 / MyIcon.ico do przeglądarki dostaję żądany zasób.

Kiedy wklejamlocalhost / MyIcon.ico do przeglądarki dostaję żądany zasób.

.svc jest jedynym typem dokumentu, który znalazłem, który zwraca 404.

Mam dwie informacje, które mogą mieć znaczenie.

Pule aplikacji. Kiedy zmieniam pulę aplikacji DefaultWebSite na TargetAppPool, 404 staje się 500 („Nie można zmapować ścieżki” / „”). Wszystkie pozostałe żądania są udane po wprowadzeniu tej zmiany. Nie jestem pewien, czy to istotne, czy nie.

Dziennik FREB (Failed Request Tracing). Znalazłem stronę (http://blogs.msdn.com/b/asiatech/archive/2011/08/25/return-404-4-not-found-when-url-rewrite.aspx), który szczegółowo opisuje kroki w dzienniku FREB, gdy przepisanie adresu URL jest bardziej udane niż moje (później zawiedzie). Nie byłem w stanie dowiedzieć się, jak wygenerować dziennik FREB dla pomyślnego przepisania (jeśli to możliwe), więc mogę porównać tylko mój dziennik FREB do tego na tym blogu. Widzę, że ich krok 21 (URL_CHANGED) w moim dzienniku FREB, ale nie 22 (URL_REWRITE_END). Nie mam wystarczającego doświadczenia z tymi dziennikami, aby zauważyć coś ważniejszego niż te (mile widziane sugestie).

Moje główne pytanie brzmi: czy ktoś wie, dlaczego tylko adresy URL żądające zasobów .svc nie są przepisywane?

Drugie pytanie brzmi: czy ktoś wie, jak wygenerować dziennik FREB dla pomyślnego żądania (jeśli jest to możliwe)?

Dzięki

Aktualizacja:

Zmieniłem architekturę, aby uzyskać więcej informacji.

Przeniosłem witrynę Target na inny komputer, na którym zainstalowałem Monitor sieci Microsoft, aby przechwycić ruch przychodzący.

Zanim zmieniłem regułę url-rewrite, aby wskazywała na tę nową stronę, otrzymałem poprawną odpowiedź, kiedy wysłałem żądanie do MyService.svc na nowym komputerze. W porządku.

Jak tylko zmieniłem regułę przepisywania, aby skierować żądanie do nowej strony docelowej, odpowiada tak jak poprzednio (404). Zrobiłem zarówno żądania POST, jak i GET. W dzienniku Monitora sieci nie ma żadnych znaków żądań (wszystkie inne wywołania -200, 404 lub w inny sposób pojawiają się w tym dzienniku).

Prowadzi mnie to do wniosku, że istnieje coś niezgodnego z poleceniami url-rewrites i * .svc. Próbowałem wykonać żądanie do MyService.asmx (po utworzeniu tego pliku) i poprawnie zwrócił stronę, więc jest ograniczony do * .svc. Jakieś pomysły?