title: WebRequest from localhost to localhost : why is it being denied?
body: <p>My app uses a WebRequest at certain points to get pages from itself.</p>
  
  <p>This shouldn't be a problem.  It actually works fine on the server, which is a "shared" hosting package with Medium trust.  Locally, I use a custom security policy based on Medium trust, which includes the following &#8212; copied straight from the default Medium trust policy:</p>
  
  <pre>
  &lt;IPermission
    class="WebPermission"
    version="1"&gt;
      &lt;ConnectAccess&gt;
          &lt;URI uri="$OriginHost$"/&gt;
      &lt;/ConnectAccess&gt;
  &lt;/IPermission&gt;
  </pre>
  
  <p>The offending line is in a custom XmlRelativeUrlResolver:</p>
  
  <pre><code>public override object GetEntity( System.Uri puriAbsolute, string psRole, System.Type pReturnType )
  {
      return _baseResolver.GetEntity( puriAbsolute, psRole, pReturnType );
  }
  </code></pre>
  
  <p>The url being requested is on localhost, in the same application as the requester.  Here's the top of the stack trace.</p>
  
  <pre>
   at System.Security.CodeAccessSecurityEngine.Check(Object demand, StackCrawlMark& stackMark, Boolean isPermSet)
     at System.Security.CodeAccessPermission.Demand()
     at System.Net.HttpWebRequest..ctor(Uri uri, ServicePoint servicePoint)
     at System.Net.HttpRequestCreator.Create(Uri Uri)
     at System.Net.WebRequest.Create(Uri requestUri, Boolean useUriBase)
     at System.Net.WebRequest.Create(Uri requestUri)
     at System.Xml.XmlDownloadManager.GetNonFileStream(Uri uri, ICredentials credentials)
     at System.Xml.XmlDownloadManager.GetStream(Uri uri, ICredentials credentials)
     at System.Xml.XmlUrlResolver.GetEntity(Uri absoluteUri, String role, Type ofObjectToReturn)
     at flow.controls.XmlRelativeUrlResolver.GetEntity(Uri puriAbsolute, String psRole, Type pReturnType) in c:\flow\source\controls\DataTransform.cs:line 105
     at System.Xml.Xsl.Xslt.XsltLoader.CreateReader(Uri uri, XmlResolver xmlResolver)</pre>
  
  <p>Anyone see the problem here?</p>
  
  <p>@Sijin: Thanks for the suggestion. The url that gets sent to the resolver is based on the request URL, and I confirmed in the debugger that accessing the site at 127.0.0.1 yields the same result.</p>