Silverlight проверяет наличие файла clientaccesspolicy.xml над корневым каталогом веб-сайта.

У нас есть странная проблема с приложением silverlight, которое, похоже, сосредоточено вокруг файла clientaccesspolicy.xml.

У нас есть веб-сайт, который является веб-сайтом по умолчанию в IIS7. В корне этого веб-сайта находится файл clientaccesspolicy.xml.

У нас также есть веб-служба, определенная в http: //thewebsite/asubdirectory/service.asmx, которая обрабатывает некоторые запросы Silverlight к веб-сайту.

Кажется, что происходит следующее: когда мы пытаемся загрузить компонент silverlight, возникает http-запрос для http: //asubdirectory/clientaccesspolicy.xml, что явно неверно.

Что странно, так это то, что если я установлю пустой веб-сайт по умолчанию и настрою этот конкретный веб-сайт как приложение / виртуальный каталог под веб-сайтом по умолчанию. например http://thewebsite/subdomain/, то запрос на clientaccesspolicy отправляется на http://thewebsite/clientaccesspolicy.xml и если я храню копию файла в корне веб-сайта по умолчанию, все работает нормально.

Что я хотел бы знать, так это то, как silverlight / IIS определяет, что ему нужно искать дальше, что корень для clientaccesspolicy, когда веб-сайт определен по умолчанию.

Может быть, это место обслуживания или ссылки на услуги в Silverlight? Есть ли разумный способ обойти это?

Большое спасибо,

Дуг


person dougajmcdonald    schedule 08.05.2012    source источник


Ответы (1)


Silverlight необходимо запросить у целевого сайта междоменную политику, если это не тот же домен. Итак, основываясь на вашем "http: // asubdirectory", я думаю, что где-то ваш код неправильный и на самом деле пытается использовать службу в http: // asubdirectory / someservice location вместо http: // thewebsite / asubdirectory / someservice.

person Alexei Levenkov    schedule 08.05.2012
comment
Я думаю, вы правы, Алексей, я надеялся не вдаваться в код, если пути предоставлены IIS или приложением silverlight, но я думаю, что нет другого варианта! - person dougajmcdonald; 09.05.2012
comment
Вы были правы, Алексей, вся эта загадочная ситуация возникла из-за того, что кто-то написал блок кода, предназначенный для извлечения значения ApplicationRoot из URL-адреса и ответа на него. Поскольку без виртуального каталога у него просто '/' в качестве ApplicationRoot, этот блок кода перемещался слишком высоко по URL-адресу и возвращал 'http: //', а не 'сайт ' - person dougajmcdonald; 09.05.2012