私はAnthonyWJonesの言葉に同意しますが、「ブラウザHTTPスタック」の意味を正確にはわかりません。
System.Net.Browser.WebRequestCreator.BrowserHttp httprequestファクトリの形式で、標準のSilverlightの「ブラウザのスタックへのアクセス」（セッションなどの処理に使用される）です（System.Net.Browser.WebRequestCreatorと比較して）。 ClientHttpファクトリ）は、WP7のアプリケーションコードで実際に使用できます。これはSDKからは隠されていますが、デバイス上で利用でき、少しの労力でアプリケーションはブラウザのキャッシュと同期して発行されたCookieを使用するなど、それを使用できます。詳細については、my humble other post
を参照してください。ただし、このファクトリを使用しているときに、ClientHttpファクトリと非常に似ているにもかかわらず、WebBrowserと同期してこれらの接続内ですべてのセッション/ Cookie/7.0および7.1バージョン）は、カスタムプレフィックスを完全に無視しています。この工場の結果と何も開こうとすると（。WP7 vをマンゴー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()
関連するコードスニペット：
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であることがわかります。
- breakpoint3 ne版Silverlightのブラウザのスタックは、プレフィックスのいくつかの組み込みのセットを使用するためにハードコードされ、他のすべての接頭辞が無視されることに起因
私の結論は、上記貼り付けられた例外にヒット/ ProtocolViolationを投げます。 WP7（7.0、7.1）では、カスタム "js：//"がBrowserHttpWebRequestに渡されたので、実際にHTTPを使用するようにハードコードされています。StackTrace上に表示されるInternalBeginGetRequestStream :)
これは、Anthonyが書いたことを確認します。カスタムプロトコルハンドラをSilverlightのブラウザスタックAPIで正常に動作させる方法はありません。
しかし、WebBrowserがこの接続ファクトリを使用していることに同意できません。隠されたファクトリがBrowserHttpと呼ばれているのは事実ですが、WebBrowserとユーザやセッションごとの設定を共有していることは間違いありませんが、WebBrowserコンポーネントが他のファクトリを完全に使用していることを示すために、おそらくそれはいくつかのネイティブなものです。それに対する議論として、私は、元のBrowserHttpファクトリを簡単なカスタム実装（エミュレータと電話機の両方）で置き換えることができ、現在のアプリケーションでは少なくとも6つのWebブラウザで、一度も使用されていませんでした。 （エミュレータでも電話でも）