Как сделать так, чтобы WebHttpBehavior for ClientAccessPolicy.xml прекратил воровство / угон корневого каталога IIS?
Я использую приложение Silverlight, которое имеет net.tcp связи WCF. Я хотел бы самостоятельно разместить ClientAccessPolicy.xml в ServiceHost, и файл политики должен находиться в корневом каталоге, порт 80, в соответствии с требованиями Silverlight net.tcp (порт TCP 4502-4534 и т. Д.). Моя проблема в том, что когда мой ServiceHost работает, он крадет корень порта 80 из IIS, и ни одна из моих веб-страниц не работает.
Код для создания конечной точки политики выглядит следующим образом:
host.AddServiceEndpoint(typeof(IPolicyGetter), new WebHttpBinding(), "http://localhost/").Behaviors.Add(new WebHttpBehavior());
Когда ServiceHost работает, я вижу http://127.0.0.1/ClientAccessPolicy.xml
, но все веб-сайты на порту 80 перестают работать - я вижу стандартную веб-страницу WCF "Конечная точка не найдена", созданную конечной точкой. Когда я отключаю ServiceHost, я вижу свой веб-сайт, но ClientAccessPolicy.xml пропал.
Я попытался использовать полный путь для URI конечной точки:
policyUri.Scheme = "http";
policyUri.Port = 80;
policyUri.Query = "ClientAccessPolicy.xml";
host.AddServiceEndpoint(typeof(IPolicyGetter), new WebHttpBinding(), policyUri.ToString()).Behaviors.Add(new WebHttpBehavior());
но это вызывает исключение аргумента. Перемещение политики в подкаталог или на другой порт не будет работать, поскольку Silverlight просматривает только порт 80 в корневом веб-каталоге.
Очевидно, что я могу просто скопировать ClientAccessPolicy.xml в корневой веб-каталог и отключить конечную точку политики. Есть ли способ нажать кнопку на конечной точке, чтобы он только перехватывал вызовы ClientAccessPolicy.xml, но не крал весь порт IIS 80?
1 ответ
Нет, два процесса не могут прослушивать один и тот же порт TCP/IP. Если ваш ServiceHost прослушивает порт 80, то он будет единственным процессом, отвечающим на подключения к этому порту.
Сказав это, вы можете иметь "главный" процесс, прослушивающий порт 80 и перенаправляющий соединения на "дочерние" процессы, но это выходит за рамки и намерения ServiceHost.