One .NET to Catch Them All. I have been coding for a long time. I…
Tags: Software Development, Dotnet, Programming, Software Testing, Web Development

Photo by Jonas Jacobsson on Unsplash

I have been coding for a long time. I have been coding since before the days of the internet. In fact, I learned on keypunch cards. In any case, when the Internet came on the scene in the nineties EVERYONE needed a web site. A dotcom identity was the ticket to riches…or at least everyone thought so.

Being able to code up a web site meant one was very employable, so of course I was doing exactly that. I was working for a consulting firm and a bunch of VBScript code was dumped on me, known as Classic ASP today. The technology was actually referred to as Active Server Pages back then. It made creating CGI functionality on web site a lot easier, so it caught on fast.

In those days, everything was a full round-trip to the server. The client page in browser would POST to an ASP page on the server, which would extract the variables and do “something” with them. After that it would just redirect back to the page that called it or to some other page the site design required.

Given this model for most interactions having a test page on the server to “catch” a POST could make things easier. First, you could see what your page was sending and fix any obvious bugs or typos. Next you could easily code up the page receiving the POST simply by reviewing the interactions with the test page. Every 20th century ASP web developer had a page with this code->

For x = 1 to Request.Form.Count

Response.Write x & ": " _

& Request.Form.Key(x) & "=" & Request.Form.Item(x) & "<BR>"

Next

This code revealed everything (value and name) being sent on the form POST and put it right there in front of you.

Nowadays things are a bit more complicated with REST APIs everywhere, tools like Fiddler, Chrome Dev Tools and Postman can now take the place of the Classic ASP Post Catcher page. Still even with these tools, sometimes one is faced with a situation when working for a remote client, where you are unable to easily control the POST being sent to you. Tight network security and dysfunctional business leaders mean someone else is at the keyboard using someone else’s code, but you want that contract!

Instead, you are dependent on your remote client to set things up and target a URI on a server/Docker/VM you control to hit your service. Perhaps the documentation for the POST you are trying to receive is a little sketchy. Perhaps you are just in a hurry to see what is being sent to you. If you are an Old Coder, you pine for the simplicity of having a page to catch any POST and see what it contained.

I just wanted to see what was coming over, so I could decide how to parse the data that was being sent over to my service. I determined that it would be a lot simpler if I could have a bullet-proof bit of code on my side which ANYTHING could POST information on without causing a blow out. In that way, I could have the client send a lot of different examples and the code on my side would store up what it got in each instance.

It turned out that this bit of code inside an MVC controller essentially did what I needed ->

[HttpPost]

public boolean Post(HttpRequestMessage inRequest)

{

string body = inRequest.Content.ReadAsStringAsync().Result; // do some stuff with that body }

Once I got the Request body into a string, I streamed it out to an FTP site, since writing to the server’s disk was not an option at that time.

In any case, I found this bit of code so useful I thought I should share the controller class it is in. Here it is. This is a class for an MVC controller in C#. So far anything I posted to it has allowed me to save off the Request information for later review.

I hope you find it useful.