Using fiddler to manually mock service response

Fiddler ( is one of those tools that make those virtually impossible tasks possible, sometimes even easy.

This post will describe how to use fiddler to mock responses from a service, but first I will describe the problem we faced, and why fiddler made the investigation so easy.

One of the integration points in a large SOA solution we are working on was an Oracle Application Server MTOM service being consumed by a WCF .NET 3.5 client to upload and download large data packets. All was working fine (perhaps surprisingly) until the client platform moved to .NET 3.5 SP1, where the download operation failed with an invalid MIME header exception. We did of course try to identify the issue by reading through the specifications, but after circling through the MTOM, SOAP 1.2 and MIME spec’s a few (dozen) times with no real output we decided to try another approach. This is where fiddler came in we were able to capture the response from the service and investigate the causes of the MIME header exception by pushing through amended requests – not quite so unscientific as trial and error, but not far of!

Firstly fire up fiddler execute the service and capture a response saving it to a file. An easy way to filter the requests of interest from all the other extraneous HTTP traffic is to use the Filters tab to filter traffic only from an identified host:


Edit the saved response as required, then on the fiddler Rules menu select the Automatic breakpoints and choose before request (short cut key F11). This will stop the request before hitting the server allowing you to supply your edited request instead. Once the client makes the request you will notice the request held in a breakpoint in fiddler:


Note that fiddler in the breakpoint fiddler will let you choose the response to send to the client; drop down the choose response combo in the breakpoint and select your amended response. Finally  press run to completion which will push the amended response on to the client where you can continue or debug as required.

This sort of service mocking can (of course) be automated with fiddler, which can be really useful during development, but this manual approach allowed easy editing of the response headers to allow us to identify the issue relatively quickly. For info the interop issue is with both Oracle and Microsoft. I can’t see the fix being as quick as the investigation…