OK,  so I’m working on something that will leverage Sql Server Reporting Services under the hood and I decided I needed to learn a tad more about how the MS-provided ReportViewer does its magic to communicate to the server.  So, of course, the first place I go is Reflector.  Well, from what I could see, the report viewer is completely married to the Report Server in a highly coupled, and terribly sealed fashion (my hope was to sneak into the processing and make the calls myself, suppling the results to the viewer).  I also wanted to see the http traffic from my web server to the [separate] report server.  So, I busted open Fiddler (which rocks the casbah), and proceeded to check out the http traffic coming into the Reporting Server….or so i thought.  What a pain!

Well,this turned into a tad bit of work/research, mainly due to my relative ignorance with these tools, and really the concept of proxying when making web service calls, and http’s Keep Alive.  The bottom line was that I was unable to successfully see the http/soap messages for a successfully loaded report via Fiddler until i had this magic recipe in place, and thought I’d share (I’ve seen lots of posts out there with people having issues, when trying to do web service calls with a proxy involved).  Have these things in place, and while you may have the occasional HTTP 502 (connection failed, resulting in the dreaded “the underlying connection was closed” message), this works  decently:

• Have Fiddler running on the server which has the web service(s) (my case Report Server):
  • Ensure “Options/Reuse connections to servers (blah blah)” is checked ON
  • Set your listen port (we’ll use 1234 for this post) for Fiddler to chill on.
• Within the website server (which in my case was a separate server, with my site acting as the client, containing the ReportViewer):
  • Anywhere your code is using a web reference, instead, create a sub-class which overrides the GetWebRequest(Uri) method (see below), and use that guy instead:

  HttpWebRequest webRequest = (HttpWebRequest)base.GetWebRequest(uri);
  webRequest.KeepAlive = true;

  • NOTE: From what i could tell, you can’t influence the ReportViewer’s keep alive, as it internally makes calls to the server in private methods, creating HttpWebRequests.
• Since I was jumping from one machine to another, I found it best to conduct my proxy setting via configuration (just  note that .net 2.0 brought some apparently much-needed improvements when working with proxies):
  <system.net>
  <defaultProxy useDefaultCredentials=“false“>
  <proxy usesystemdefault=“False“
  proxyaddress=http://servername:1234
  bypassonlocal=“False“ />
  </defaultProxy>
  </system.net>
• And finally, within Fiddler, I went to Rules\Customize Rules…, which opens up the MS script editor, loading in Fiddler’s apparrent CustomRules.js file.  Go to the OnBeforeReponse function, and uncomment the last couple of lines at the bottom.  The Fiddler Known Issues lists this detail about the “Underlying connection closed” issue.

See, that was’nt so bad! 😉