WebRequest.RegisterPrefix for http:// returns true, doesn't work - networking

Question

I'm trying to use WebRequest.RegisterPrefix to register a decorator IWebRequestCreate implementation with the intention being to add "debug" scenarios (like emulating different connectivity scenarios).
I'm using the Mango beta 2 SDK and the RegisterPrefix method always returns true when used with "http://" as a prefix (or "http" for that matter), but the registered IWebRequestCreate instance is not being used.
I can see from the documentation that it should return false for duplicates, but it doesn't seem to be functioning as documented.
Is there any other way of achieving what I'm after in a way that is transparent to consumers?

Answer 1

I'm using WebRequest.RegisterPrefix for unit testing, registering an IWebRequestCreate implementation for a prefix of test://, and this does work.
I found that after registering an IWebRequestCreate for http://, calling WebRequest.Create with an http:// uri would return a request created from the registered IWebRequestCreate, but calling WebRequest.CreateHttp would still return an HttpWebRequest.
The following code should verify this, and I'm using the Mango Beta 2 SDK (6-29-11):
public partial class MainPage : PhoneApplicationPage
{
public class FakeRequest : WebRequest
{
private Uri _uri;
public FakeRequest(Uri uri)
{
_uri = uri;
}
public override Uri RequestUri { get { return _uri; } }
}
public class FakeRequestFactory : IWebRequestCreate
{
public WebRequest Create(Uri uri)
{
return new FakeRequest(uri);
}
}
// Constructor
public MainPage()
{
InitializeComponent();
// returns System.Net.Browser.ClientHttpWebRequest
var request1 = WebRequest.Create("http://www.foo.com");
// returns System.Net.Browser.ClientHttpWebRequest
var request2 = WebRequest.CreateHttp("http://www.foo.com");
// returns true
bool result1 = WebRequest.RegisterPrefix("http://", new FakeRequestFactory());
// returns FakeRequest
var request3 = WebRequest.Create("http://www.foo.com");
// returns System.Net.Browser.ClientHttpWebRequest
var request4 = WebRequest.CreateHttp("http://www.foo.com");
// returns false
bool result2 = WebRequest.RegisterPrefix("http://", new FakeRequestFactory());
// returns false, as per the note in the documention
bool result3 = HttpWebRequest.RegisterPrefix("http://", new FakeRequestFactory());
}
}

Answer 2

Hey I know this question is 2 years old but I came across the same problem. I think you'll find that WebRequest.RegisterPrefix() does return false if you try to register http: (notice the single colon, no forward slashes). If I ever find a workaround, I'll try to remember to update this post.
EDIT
In my particular case I wanted to throw out System.Net.FtpWebRequest and roll my own FTP client implementation (because the framework's implementation sucks).
In order to do that, I used reflection (and a bunch of late binding tricks) to get the arraylist of registered prefix and remove the ones that are linked to the internal System.Net.FtpWebRequestCreator class.
I'm not sure if all of these APIs are available for windows phone, but here's what I did:
Type webRequest = typeof(System.Net.WebRequest);
Assembly system = Assembly.GetAssembly(webRequest);
Type ftpWebRequestCreator = system.GetType("System.Net.FtpWebRequestCreator");
ArrayList prefixList = (ArrayList)webRequest.GetProperty("PrefixList", BindingFlags.Static | BindingFlags.NonPublic).GetValue(null, null);
IEnumerator enumerator = prefixList.GetEnumerator();
while (enumerator != null && enumerator.MoveNext()) {
if (object.ReferenceEquals(enumerator.Current.Creator.GetType(), ftpWebRequestCreator)) {
prefixList.Remove(enumerator.Current);
if (System.Net.WebRequest.RegisterPrefix(enumerator.Current.Prefix, new CustomWebRequestCreator())) {
enumerator = null;
} else {
enumerator = prefixList.GetEnumerator();
}
}
}
// Now I can use Create() on the base class
System.Net.WebRequest myCustomWebRequest = System.Net.WebRequest.Create("ftp://example.com/public");
This works by finding all prefixes that are registered with FtpWebRequestCreator and replacing them with my own creator. It should be fairly straightforward to adapt this for http(s).

Answer 3

The phone only has a client stack so RegisterPrefix has no effect on the phone.