Nail-Tinted Glasses

Mocking an HTTP POST response

The other day, I found myself wishing for an easy way to mock a web service.

Which is to say, that I wanted to hardcode the answer, without interfering with the actual service that was running. It turns out that you can accomplish this with IIS.

In my case, the URL was configurable, so I simply directed the client to point to my mock target. Had that not been the case, I could have modified my hosts file, so that the server name got mapped to the loopback address. I created the appropriate virtual root, and path underneith it, and copied my data into a simple text file with the appropriate name.

This didn't work. IIS objected to serving up static data in response to a POST request.

But an interesting feature of IIS is that it allows you to customize the error messages reported by the web server - not just globally, but also on an individual basis.

So the answer was to set up a customized error entry for that file, specifying that, in case of an error, it should respond with the contents of that file. In short, I persuaded IIS that the data was the error message.

This still didn't work in my case, which I attribute to the fact that my data file was fairly hefty (on the order of 5MB). But while IIS wasn't happy using a file of that size as an error message, it was willing to serve up that same data if I specified that the error was to be obtained via a URL.

Summarized, IIS decides that it cannot retrieve the data for a POST, so does a GET instead. A handy trick, that, and it takes much less time to actually do it than it does to discover the process.

January 21, 2003 6:22 AM | TrackBack