Я согласен с словами AnthonyWJones, хотя я не знаю, что именно он имел в виду под «HTTP-стек браузера».
Стандартный доступ Silverlight к стеку браузера (используется для обработки сеансов и т. Д.) В виде System.Net.Browser.WebRequestCreator.BrowserHttp httprequest factory (против «normal/aside» System.Net.Browser.WebRequestCreator. ClientHttp factory) фактически доступен для кода приложения в WP7. Он скрыт от SDK, но доступен на устройстве и с небольшими усилиями, приложение может использовать его, например, для того, чтобы его удаленные файлы cookie синхронизировались с кешем браузера. Для получения дополнительной информации см. my humble other post
Тем не менее, при использовании этой фабрики и при использовании всех ваших сеансов/файлов cookie/userauth в этих соединениях в синхронизации с WebBrowser, несмотря на то, что они очень похожи на фабрику ClientHttp, вы найдете (по крайней мере, в Версии 7.0 и 7.1), что он полностью не знает каких-либо пользовательских префиксов. При попытке открыть что-нибудь с этим фабричных приводит (. WP7 против манго 7,1):
A first chance exception of type 'System.Net.ProtocolViolationException' occurred in System.Windows.dll
at System.Net.Browser.BrowserHttpWebRequest.InternalBeginGetRequestStream(AsyncCallback callback, Object state)
at System.Net.Browser.AsyncHelper.BeginOnUI(BeginMethod beginMethod, AsyncCallback callback, Object state)
at System.Net.Browser.BrowserHttpWebRequest.BeginGetRequestStream(AsyncCallback callback, Object state)
at MyApp.MyPage..ctor()
соответствующий код фрагмент из MyPage:
public class WRC : IWebRequestCreate { public WebRequest Create(Uri uri) { return null;/*BREAKPOINT1*/ } }
WebRequest.RegisterPrefix("js://", new WRC()); // register the above handler
brwHttp = (IWebRequestCreate)typeof(System.Net.Browser.WebRequestCreator).GetProperty("BrowserHttp").GetValue(null, null);
var tmp = brwHttp.Create(new Uri("js://blah.blah.blah"));
var yyy = tmp.BeginGetResponse(callback, "wtf");
var response = tmp.EndGetResponse(yyy); /*BREAKPOINT2*/
var zzz = tmp.BeginGetRequestStream(callback, "wtf"); /*<---EXCEPTION*/
var stream = tmp.EndGetRequestStream(zzz); /*BREAKPOINT3*/
Результаты исполнения:
- breakpoint1 никогда не ударил
- breakpoint2 позволяет видеть, что «ответ» равен NULL
- точка останова3 n когда-нибудь ударил из-за исключением вставленного выше
Мой вывод, что стек Silverlight Browser является жёстко использовать некоторый набор встроенный префиксов, а все остальные префиксы игнорируются/выбросить ProtocolViolation. Мое предположение, что в WP7 (7.0, 7.1), они на самом деле зашиты использовать HTTP, так как мои пользовательские «JS: //» был передан в BrowserHttpWebRequest .InternalBeginGetRequestStream, как это видно на StackTrace :)
Это подтверждает то, что написал Антоний, - никоим образом не может заставить обработчиков протоколов работать изящно с помощью API стека браузера Silverlight.
Однако я не могу согласиться с тем, что WebBrowser использует эту фабрику соединений. Хотя верно, что скрытая фабрика называется браузеромHttp, и верно, что она разделяет некоторые настройки для каждого пользователя или каждого сеанса с помощью веб-браузера, все, что я пытаюсь сделать десятками, чтобы указать, что компонент WebBrowser использует еще полностью другой завод для своих соединений, и, вполне вероятно, это какой-то родной. В качестве аргумента для этого я могу только предоставить, что я смог успешно заменить исходную фабрику BrowserHttp своей простой пользовательской реализацией (как на эмуляторе, так и на телефоне) и с по меньшей мере 6 веб-браузерами в моем текущем приложении. вообще не использовался, ни разу! (ни на эмуляторе, ни на телефоне)