Collect network trace data within your ASP.NET application
If you read one of my previous posts about reverse engineering of a shortened URL, then you probably saw the comment from Richard Deeming, saying that there is a better approach to achieve the task. The comment was about to avoid unnecessary trip between the client and the server and I have added an update to my post – please see the following post, if you haven’t seen it yet and you are interested in:
How to reverse engineer a shortened URL
https://blogs.msdn.com/b/amb/archive/2011/02/13/how-to-reverse-engineer-a-shortened-url.aspx
While I was thinking about Richard’s comment, I thought that would be great to see the differences between both approaches by collecting network trace. Unfortunately, it may be very difficult to collect network traces sometimes so you need to find another way to see the packets flying in the network.
Thanks to .NET Framework, we have useful diagnostic namespaces and classes for System.Net to log the network activity since .NET Framework 2.0. So I decided to check this pretty cool way and it was easier than I thought.
Scenario
I have used the following code snippet to get the Location header of an HTTP response from an ASP.NET 2.0 (or 3.0, 3.5 and 4.0) application.
HttpWebRequest request = (HttpWebRequest)(WebRequest.Create(url));
using (HttpWebResponse response = (HttpWebResponse)request.GetResponse())
{
string uriString = response.ResponseUri.AbsoluteUri;
}
Richard has suggested the following one to avoid unnecessary round-trip:
HttpWebRequest request = (HttpWebRequest)(WebRequest.Create(url));
request.AllowAutoRedirect = false;
using (HttpWebResponse response = (HttpWebResponse)request.GetResponse())
{
string uriString = response.Headers["Location"];
}
Now we would like to know if the second approach really avoids the unnecessary round-trip. However, we cannot collect a network trace from either the our IIS or the target server.
So the question is how do we log the HTTP web requests and responses (such as the ones done via HttpWebRequest and HttpWebResponse objects) in an ASP.NET web application?
Solution
We have useful System.Net diagnostic features since .NET 2.0. So we can use those skills. To start using it, just add the following lines in your web.config file:
<system.diagnostics>
<sources>
<source name="System.Net" tracemode="includehex" maxdatasize="1024">
<listeners>
<add name="System.Net"/>
</listeners>
</source>
<source name="System.Net.Sockets">
<listeners>
<add name="System.Net"/>
</listeners>
</source>
<source name="System.Net.Cache">
<listeners>
<add name="System.Net"/>
</listeners>
</source>
</sources>
<switches>
<add name="System.Net" value="Verbose"/>
<add name="System.Net.Sockets" value="Verbose"/>
<add name="System.Net.Cache" value="Verbose"/>
</switches>
<sharedListeners>
<add name="System.Net"
type="System.Diagnostics.TextWriterTraceListener"
initializeData="c:\tracelogs\network_trace.log"
/>
</sharedListeners>
<trace autoflush="true"/>
</system.diagnostics>
The lines above are taken from the following article:
How to: Configure Network Tracing
https://msdn.microsoft.com/en-us/library/ty48b824(v=VS.100).aspx
If you look closely, network trace information will be logged in c:\network_trace.log. Of course you can change it - you may need write permission for the user who runs the application pool, so you may want to set this folder in a different location and give necessary permissions on it.
That’s it. When you run your application, HttpWebRequest and HttpWebResponse activity should be logged in c:\network_trace.log.
Conclusion
When I checked the log files for both approaches, it was pretty obvious that Richard’s way was avoiding the unnecessary round-trip.
There was also one another advantage which was a performance booster: log for Richard's approach was much smaller than mine as Richard's suggestion did not allow the request to be redirected, so it only logged the first response from the server, which was an HTTP redirect response, such as 301, 302 or 307. Thus we did not get unnecessary HTTP packets – this is especially useful when the target web page we made an HTTP request to is quite big. Richard's method was more useful than I expected.
References
How to: Configure Network Tracing
https://msdn.microsoft.com/en-us/library/ty48b824.aspx
How to reverse engineer a shortened URL
https://blogs.msdn.com/b/amb/archive/2011/02/13/how-to-reverse-engineer-a-shortened-url.aspx
Network Monitor 3.4
https://www.microsoft.com/downloads/details.aspx?FamilyID=983b941d-06cb-4658-b7f6-3088333d062f
Fiddler
https://www.fiddler2.com/fiddler2/
Applies To
.NET 2.0
.NET 3.0
.NET 3.5
.NET 4.0
--
AMB