This article is not about understanding the details of .Net WCF service, soapUI and Fiddler as all these three are quite popular things among .Net developers. And tools like soapUI and Fiddler may already be in the arsenal of many web developers and QA engineers. Those who are new to these two tools should refer to following articles.
However, we will take a look into how Fiddler can be used to Monitor SOAP Request and SOAP Response transmitting behind the soapUI.
Let’s start with a simple WCF service in place. No need to have a WCF .Net Client as of now to test and monitor HTTP traffic of WCF service calls.
1. Open soapUI and set the following settings. Make sure the service’s wsdl path is correct.
2. After loading the definition of WSDL, service definitions will appear like shown below.
3. Double click on Request # node and navigate to the request window on the right.
4. Fill the method parameters denoted by “?”.
5. Open Fiddler and make sure it is ready to capture HTTP(S) traffic.
6. Submit request to the specified endpoint and SOAP Response can be seen on the right pane.
7. If you see the Fiddler window, there is no traffic captured. This is really frustrating if you have been testing your services using soapUI when you do not see the underlying details of the SOAP Request and SOAP Response in the wire.
8. All you need to do following proxy settings in the soapUI File –> Preferences –> Proxy Settings window.
9. Re-submit web service request on soapUI.
10. Now you see WCF Request-Response traffic in the Fiddler window . You are now all in your territory to view the details of service request-response headers, body, and many more!
But why did we add Port No. 8888 in the proxy settings of soapUI? It is because Fiddler by default listens on port no. 8888.
If you have configured your Fiddler proxy tool to listen on some other port no., then you should use that one.
I hope you enjoyed this testing tip. No need to reiterate how blissful it is to test web services using soapUI and Fiddler if you are a web service developer/provider to remote clients.
I have been working with one project in ASP.Net for quite long time. Most of the time, I see my colleagues fixing some problems by debugging .Net code. It is a very good way to understand application codes and .Net classes and objects. But what I feel is that Asp.net developers should equally try to know browsers they are using. When we come to browser, there comes HTTP protocol, GET/POST methods, headers, session, cache, cookies, content-type, status codes, etc. And we know all these objects are not far from Asp.net web pages or say request and response. If we know and take care of these things while debugging the application, I am sure we can save lots of time to fix the problems.
Fiddler tool can be used to know details of HTTP web request, response and many other objects that are part of web pages and browsers. Fiddler is an HTTP Debugging Proxy which logs all HTTP traffic between your computer and the Internet. But while debugging Asp.net application with Fiddler, one should not use ‘localhost’ as the machine name in the address bar; we have to use computer name or IP address.
One thing that I found very useful about this tool is HTTP response status codes returned for all the requests made. And of course, its capability to show Parent Request, Child Requests and Duplicate Requests of any content-type. One can see from the figure shown below.Fig 1: Fiddler used to capture HTTP traffic
When we look at Result column on the left grid, we may see mostly 200, 204, 301, 404, 501, etc. like numeric codes. These are nothing but HTTP response status codes returned for each content or request type. These status codes have different meaning. I would like to summarize here in brief.
Status Codes Summary to remember:
|1xx Informational||Request received and continuing the process|
|2xx Success||Client request successfully received, understood and accepted|
|3xx Redirection||Generally URL redirection|
|4xx Client Error||Request contains bad syntax, IIS permissions, wrong paths of any content|
|5xx Server Error||Server error when request arrived|
1xx can be 101 or 102. Similarly, 2xx can be 204 or 206. The post fix xx will be always some numbers as recognized by HTTP standard. These results can be really helpful in debugging scenario when web pages have rich contents.
Fiddler tool is very user friendly and one will always like to use it.CodeProject