Why SoapTrace.Net?

SoapTrace.Net grew out of the need to handle some misuse/abuse of soap web services on one project. Before the web service misuse, tools like Microsoft's Soap Trace, PocketSoap's TcpTrace and YATT were used alongside good old fashioned logging. Microsoft's Soap Trace was predominantly used, because it gave a nice pretty print view of the soap messages. It even handled the early abuse of web services where xml was sent as a string parameter through the soap message, leading to < > character encodings, which made viewing the raw messages either in TcpTrace or a log file painful. Microsoft's Soap Trace displayed the underlying xml, without the character encodings, so it became the main tool for debugging issues with the web services.

Then along came even more web service abuse.

To reduce bandwidth certain messages had their xml strings gzipped and then base64 encoded. Viewing these messages even in good, old Microsoft's Soap Trace was impossible. Decoding gzipped, base 64 encoding text back into its original xml using only the power of the human brain was an impossible task. If only it were possible to do some post processing of the messages before they were displayed in the GUI, then we could transform the data back into xml and debugging would become easy again.

SoapTrace.Net was born.

History

In its first incarnation, developed outside of working hours, it was just a proxy server that could display the raw soap messages, pretty print them or decode the gzipped, base 64 encoded xml. The messages were displayed in plain black and white text, and the UI was similar to Microsoft's Soap Trace's, but it did not have an MDI. It had a few NUnit tests too, just for good measure.

As well as handling the web service abuse, limitations of Microsoft's Soap Trace utility were improved upon:

  1. It occasionally crashes.
  2. It uses Internet Explorer to display the resulting soap messages. Intermittently either IE or the soap trace application gets confused and refuses to display the soap message.
  3. It cannot be customised. If for some reason you decide to send gzip/base 64 encoded data through the web service you cannot see what the actual data is.
  4. No source code is provided.
  5. The list view display of connections is not that useful if you are just interested in seeing soap messages sent from applications on your local machine. The list view displays the IP address of the connecting client application.
  6. It does not handle "chunked" http data.
  7. Proxy server only.

The next stage was to overhaul the back end, rewrite the proxy server code, which I did not like, and add packet capture functionality.

Before this happened the project was converted from Visual Studio .Net 2003 to a SharpDevelop project. The main reason for this was because SharpDevelop is great free .Net IDE, which is also open source, and the idea of being able to tinker with the code of your development environment appealed to me.

The proxy server was written and WinPcap.Net was brought into the world, a simple managed C++ wrapper around the WinPcap library.

A custom formatter plug-in architecture was added, so the application was extendable without having to hack the source code. How useful this feature is, outside of web service abuse, remains to be seen.

A SourceForge project is created for SoapTrace.Net.

Windows Raw Sockets was added to the mix, for people who do not want to install WinPcap.

Fed up with the boring black and white text, colour was added to the soap messages. First attempt involved the main form's code formatting the xml text using the XmlTextReader and a rich text box. This evolved into a Formatted Text class, which allowed the custom formatters to colour the text being displayed in the GUI.

Running some tests against CodeProject's web services, showed that the packet capture logic, which at the time was extremely dumb, needed overhauling. To help debug packet issues, alongside Ethereal, the Packet Viewer dialog was added. This shows the data packets that SoapTrace.Net received, allows them to be saved to an xml file and reloaded back into the UI.

Raw Sockets caused a bit of a headache, at least on my test machine, the standard SYN, SYN-ACK, ACK packet sequence that occurs on making a tcp connection, gets mixed up with raw sockets. For some reason the packets arrive in the sequence SYN, ACK, SYN-ACK, so we get the server's acknowledgement (SYN-ACK) of the original connection attempt (SYN) after the client has already sent out the acknowledgement (ACK) of the server's acknowledgement. Maybe Raw Sockets uses some sort of localised time travel.

All the user settings, such as form positions and layout, are saved on the local machine under "C:\documents and settings\username\Local Settings\Application Data\SoapTrace.Net" since roaming information such as the network interface being used for packet capture does not make sense.

Version 0.2

Simple logging was then added. Each matched soap request and response pair is logged to their own xml file. If the current logging implementation is not to your taste you can provide your own assembly which implements the ISoapMessageLogger interface. The soap message is actually stored in a CDATA section, the main reason for this is so if the client or server chucks out badly formed xml the log file will still be well-formed.

Message replay was added, allowing the user to select a soap request, edit the text and re-send it. Currently it does not allow the user to select multiple messages and replay them. Not sure if this will be implemented.

Version 0.3

After a request in the help forum, support for multiple proxy servers was added. SoapTrace.Net now supports a tabbed view, each tab has its own settings, so you can set up packet capture for multiple remote machines or you can run multiple proxy servers.

Version 0.4

The managed C++ WinPcap.net library was ported to C#. It uses PInvoke to call unmanaged methods provided by wpcap.dll.

The configuration file location no longer changes with a new version of SoapTrace. The location originally depended on the Application.LocalUserAppDataPath which is of the form "C:\Documents and Settings\[user]\Local Settings\Application Data\CompanyName\ProductName\ProductVersion". The config file is now stored under "C:\Documents and Settings\[user]\Local Settings\Application Data\SoapTrace.net".

Version 0.5

Some small usability changes:

  1. Middle clicking a tab closes it.
  2. Tab right click context menu. Menu options "Close tab" and "New Tab".
  3. New tab menu option now displays the settings dialog.
  4. Added an "Undo Close" menu option. Remembers the settings for the last 5 closed tabs.

Added some performance improvements so large XML files are displayed quicker. It takes about 1.5 seconds to display a 40KB soap message, down from taking 15 seconds. This is still a bit slow, but further improvements will probably require me ripping out the RichTextBox and using a custom control. Colouring the text in a RichTextBox seems to generally be quite slow.

You can now choose to show the application in the TaskBar Notification Area, more commonly and incorrectly known as the System Tray

Fixed a bug where the application prevented the user from logging off or shutting down.

Added .NET 2.0 to the configuration's supported runtimes so SoapTrace will run with just .NET 2.0 installed

Can now run SoapTrace under different user accounts at the same time. Previously you would see an access denied error as the SoapTrace application tried to access another's mutex.

Fixed a bug where the formatting was off if the soap message contained newlines instead of a newline and carriage return pair.

Version 0.6

SoapTrace did not work with WinPcap 3.1 since the pcap_findalldevs_ex method used different parameters to the one with WinPcap 3.0. The code has been modified to use the older pcap_findalldevs which works with both versions.

Version 0.7

The code has been modified to work with .NET 2.0 and can now be opened and compiled with Visual Studio or on the command line with MSBuild.