Let's see how to use Fiddler to send an HTTP request to our local Web API and check the response. Step 1: Download and install Fiddler from here. Step 2: After successful installation click on Fiddler.exe to open Fiddler. It will look like the image below. Fiddler by default captures all processes. The Fast Infoset message encoding of WCF-Xtensions produces the most compact messages compared to any system-provided message encondings available in WCF. HTTP content negotiation The HTTP content negotiation binding element enables you to support multiple message encodings and compression methods on the same endpoint for serving different clients.
EAS Inspector for Fiddler will provide users with a sample application to showcase the process of decoding Exchange Server ActiveSync (EAS) WBXML into XML within a Fiddler Inspector environment.
Charles 3.7 beta 2 has been released. This changes the SSL signing for Charles on Mac OS X to use Apple's new Developer ID code-signing. Charles v3.6.5 released including bug fixes and minor changes. Charles v3.6.4 released including major bug fixes and enhancements.
Be aware, though, that this sample does not provide general WCF host support for ASP.NET Core. Among other things, it has no support for message security, WSDL generation, duplex channels, non-HTTP transports, etc. The recommended way of providing web services with ASP.NET Core is via RESTful web API solutions.
He has a WCF Header.. Get it
Often, you'll need to pass some piece of information on some or all of your WCF Service operations. For my team, we had recently exposed some functionality in an old WCF Endpoint via a Web Front End and wanted to log some auditing information on each and every Service Call. Obviously modifying every single method signature to accept the new parameters would be a pretty significant breaking change to all the consumers so instead we looked at passing this information as a Custom WCF Message Header. WCF exposes a number of interfaces which you can leverage to inspect & modify messages on the fly and to add customer behaviors to service endpoints. In the following demo, we'll go through the process of building a Custom Header for our WCF Service & subsequently passing that information from the Consumer Client back to the service. In our contrived example I'll be attempting to pass 3 pieces of information to the WCF Service as part off every message call.
The username of the currently logged in web front-end user
Since our website is deployed across multiple nodes, the id of the web node
The 'Special Session Guid' of the current users Session
[important]The completed solution can be found on GitHub at https://github.com/eoincampbell/wcf-custom-headers-demo [/important]
This scenario could apply to a number of other real world situations. Perhaps the service is secured and called using a single WS Security Account, but we need to log the user who's session, the service call originated from on every service call. Or perhaps you're exposing your service to the public and as well as providing a username & password to authenticate, the caller also needs to provide some sort of 'Subscription Account Number' in addition to their Credentials. Any of these scenarios are candidates for adding a custom header to a WCF Service.
Of course I could just edit method signatures of each service call to accept this additional information as additional parameters but this causes a number of other problems. This might be feasible for a small in-house service, or dummy application but it causes a number of issues in reality.
I need to add additional parameters to every service call which isn't a particularly elegant solution
If I need to add more information in the future, I must edit every service call signature which at worst is a breaking change for every client and at best, a significant amount of work & re-factoring.
Depending on the scenario, I'm potentially intermingling Business Logic with Authentication/Authorization or some other sort of Service Wide Validation logic which is going to increase the complexity of any future re-factoring.
A better solution would be to 'tag' each service call with some sort of header information. In this way, we could piggy-back our additional data along without interfering with the individual method signatures of each service call. Thankfully WCF includes built-in support for MessageHeaders. The services OperationContext includes Incoming & Outgoing Message Header collections.
For now I've created a very simple Service Contract which has a single void method on it called DoWork(). Adding a custom header to this service call is relatively trivial. First we instantiate a new instance of our WCF Client Proxy. We also nee to create an OperationContextScope using the WCF client channel. Since the OperationContext is accessed, via the static Current property, instantiating this scoping object, stores the current context & the OperationContext of the current Clients IContextChannel becomes that returned by the Current Property. This allows us to modify the OutgoingMessageHeaders collection of the clients channel. Once disposed the state of the original Current OperationContext is restored. MessageHeaders are passed as untyped data as they travel on the wire. In the example above I've created a strongly typed .NET object. That is then converted to an untyped header; keyed by name & namespace for transmission in the OutgoingMessageHeaders Collection. If we observe the data that travels across the wire using fiddler, we can see our Custom Header Data has been appended to the soap header section of the message.
Fiddler WCF Headers
Finally, these Header values can be retrieved from the IncomingMessageHeader Collection as part of the service call processing. Since we're already in the scope the Current OperationContext, we can just directly access that context's header collection to read our headers. I've added a simple generic helper method to test to see if the Header can first be found and if so, will be returned.
The above solution comes with some pros and cons. On the plus side headers can be added in an adhoc manner with little friction to existing code. On the downside, it's not really ideal from a code maintenance/organization point of view. Header Data is relatively unstructured and disparate. We also end up with a lot of touch-points. Adding headers requires creating an OperationContextScope in close proximity to every service call.. similarly, accessing the resultant header values must be done in the Service Methods.. Imagine our WCF Service had 100 service methods, and all we wanted to do was send a single additional header to be logged on the server. That results in 100's of lines of additional code.
A better solution would be to use the built in message inspector interfaces in WCF. Message Inspectors provide you with a way to plug directly into the WCF Communications Pipeline on both the client or server side of the communication Channel. The IDispatcherMessageInspector allows us to affect messages either just after the request has arrives on the server (AfterReceiveRequest) or just before the response leaves the server (BeforeSendReply) The IClientMessageInspector allows us to affect messages either just before the request leaves the client (BeforeSendRequest) or just after the response is received by the client (AfterReceiveReply)
Injecting ourselves into the message pipeline like this serves a number of advantages, We now have the opportunity to add our messages to the outbound client request in a single place. We also have a single touch point for capturing the request on the server side. If this was a licence-code validation check, this would save us from peppering every single service call with the validation check code.
In the following sections we'll look at creating a custom data header object, creating a message inspector implementation to manage injecting and extracting this data from our WCF Service, creating Client & Service Behaviors to attach our Message Inspectors and creating a behavior extension to allow these behaviors to be applied to our service through configuration.
Since both our Web Application (which will host the Web Services) and the Console Application will have some common dependencies, I've split out the majority of the code in these next sections and stored them in Common Class Library folder which both Applications can then reference.
Solution Organisation
The first thing I'll create is a simple data contract object to represent our custom header information. This POCO Data Contract provides a simple way for us to encapsulate our header information into a single payload which will be transmitted with our Service Calls.
Next I create our Message Inspectors. The two interfaces that are required are the System.ServiceModel.Dispatcher.IDispatchMessageInspector (which hooks into our pipeline on the service side) and the System.ServiceModel.Dispatcher.IClientMessageInspector (which hooks into our pipeline on the consumer side). Within these two interfaces the two methods I'm most interested in are the IClientMessageInspector.BeforeSendRequest which allows me to modify the outgoing header collection on the client and the IDispatchMessageInspector.AfterReceiveRequest which allows me to retrieve the data on the service side.
I'll also need to create a simple static Client Context class which will provide the conduit for the Consumer Application to set header values to be picked up inside the message inspector methods.
WCF Service Behaviors define how the endpoint (the actual service instance) interacts with its clients. Attributes like security, concurrency, caching, logging, and attached message inspectors - those are all part of the behavior. We're going to implement a new custom behavior for both the Service side and the Client side of this interaction. Since these are still just interface implementations, there's no need to create a new class to implement them. We can add this functionality to the same class which contains our Message Inspector functionality. Of course if you wanted to be a purist about it, there's nothing to stop you implementing the two message inspectors and two service behaviors in four completely separate classes.
The two behavior contracts I'm interested in here are the System.ServiceModel.Description.IEndpointBehavior, which is responsible for the client side behavior and the System.ServiceModel.Description.IServiceBehavior which is responsible for the service side behavior. Implementing these interfaces allows me to add an instance of the Message Inspectors to the service.
Behaviors can be applied to services using a special Service Behavior attribute which decorates the ServiceContract. The last step is to extend the Attribute class in our CustomHeaderInspectorBehavior class and then to decorate each of services with that attribute.
On the client side, I need to do a tiny bit more work. I can manually configure the Behavior on the WcfClientProxy every time I instantiate it but this is extra bloat and eventually I'll forget to set it somewhere and lose my behavior functionality.
Instead I'd prefer to be able to set this once in configuration and never have to worry about it again. I can achieve this by using a BehaviorExtension Element as follows and adding it to my application configuraiton file.
And below is the equivalent configuration file.
Finally, we can call our client and test to see if our Server side application can see the headers being submitted and echo them back.
WCF Header Demo Result
Excellent.
~Eoin Campbell
Recent Developments
For discussion on the latest changes to Charles, please see Karl’s blog.
15 Nov 2020
Charles 4.6.1 released to fix Dark Mode support on macOS Read more.
7 Nov 2020
Charles 4.6 released including new features and stability improvements. Read more.
15 Jan 2020
Charles 4.5.6 released with minor bug fixes and patched security vulnerability. Read more.
5 Dec 2019
Charles 4.5.5 released including bug fixes for SSL certificate imports. Read more.
3 Nov 2019
Charles 4.5.2 released including new features, bug fixes and improvements. Read more.
28 Feb 2019
Charles 4.2.8 released with minor bug fixes. Read more.
14 Sep 2018
Charles 4.2.7 released with minor bug fixes and improvements. Read more.
5 May 2018
Charles Security Bulletin for a local privilege escalation in Charles 4.2 and 3.12.1 and earlier. Read more.
7 Apr 2018
Charles 4.2.5 released with major bug fixes and minor improvements. Read more.
28 Mar 2018
Charles for iOS released. Read more.
22 Nov 2017
Charles 4.2.1 released with important bug fixes. Read more.
30 Sep 2017
Charles 4.2 released with major new TLS debugging capability, minor improvements and bug fixes including macOS High Sierra support. Read more.
10 Jul 2017
Charles 4.1.4 released with minor improvements and bug fixes. Read more.
20 Jun 2017
Charles 4.1.3 released including Brotli compression support and other minor bug fixes and improvements. Read more.
13 May 2017
Charles 4.1.2 released with bug fixes and minor improvements. Read more.
21 Apr 2017
Charles 4.1.1 released with bug fixes. Read more.
10 Apr 2017
Charles 4.1 released including major new features and bug fixes. Read more.
19 Nov 2016
Charles 4.0.2 released including bug fixes and minor improvements. Read more.
Wcf Binaryencoded Message Inspector For Fiddler For Mac Os
20 Sep 2016
Charles 4.0.1 released including bug fixes. Read more.
16 Sep 2016
Charles 3.11.6 released with support for macOS Sierra and minor bug fixes. Read more.
1 Aug 2016
Charles 4 released featuring HTTP 2, IPv6 and improved look and feel. Read more.
29 May 2016
Charles 3.11.5 released including minor bug fixes; especially fixes SSL certificate installation on Android. Read more.
29 Feb 2016
Charles 3.11.4 released with support for ATS on iOS 9 and crash fixes for older versions of Mac OS X. Read more.
15 Feb 2016
Charles v3.11.3 released including bug fixes and minor improvements. Read more.
9 Nov 2015
Charles v3.11.2 released with SSL and Websockets improvements. Read more.
4 Oct 2015
Charles 3.11 released including major new features. Read more.
7 Jul 2015
Charles 3.10.2 released with bug fixes and improvements. Read more.
31 Mar 2015
Charles 3.10.1 released with minor bug fixes. Read more.
21 Mar 2015
Charles 3.10 released with improved SSL (new SSL CA certificate install required), major new features and improvements. Read more.
22 Oct 2014
Charles v3.9.3 released with improvements to SSL support, Mac OS X Yosemite support and other minor bug fixes and improvements. Read more.
26 May 2014
Charles v3.9.2 released with minor bug fixes. Read more.
5 May 2014
Charles 3.9.1 released with minor bug fixes and improvements. Read more.
25 Apr 2014
Charles 3.9 released with major new features and bug fixes, including the ability to 'focus' on hosts so they are separated from the noise. Read more.
23 Oct 2013
Charles 3.8.3 released with support for Mac OS X Mavericks and minor bug fixes. Happy Mavericks Day. Read more.
21 Oct 2013
Charles 3.8.2 released with minor bug fixes. Read more.
9 Sep 2013
Charles 3.8.1 released with minor bug fixes and improvements. Read more.
4 Sep 2013
Charles 3.8 has been released with new features and bug fixes. Read more.
12 Feb 2013
Charles 3.7 has been released. Includes new features, bundled Java runtime (so you don’t need to install Java anymore), and bug fixes. Read more.
27 Jun 2012
Charles 3.7 beta 2 has been released. This changes the SSL signing for Charles on Mac OS X to use Apple's new Developer ID code-signing. Read more.
Wcf Binaryencoded Message Inspector For Fiddler For Mac Catalina
8 Dec 2011
Charles v3.6.5 released including bug fixes and minor changes. Read more.
15 Nov 2011
Charles v3.6.4 released including major bug fixes and enhancements. Read more.
5 Sep 2011
Charles v3.6.3 released including minor bug fixes. Read more.
24 Aug 2011
Charles v3.6.1 released including minor enhancements and bug fixes. Read more.
18 Aug 2011
Charles v3.6 released including new features, enhancements and bug fixes. New features include HAR and SAZ file import. Read more.
17 Aug 2010
Charles v3.5.2 released including bug fixes and minor new features. Read more.
1 Jan 2010
Charles 3.5.1 released. Minor bug fixes. Read more.
23 Dec 2009
Charles 3.5 released. Major new features, bug fixes and enhancements.
17 Oct 2009
Charles 3.4.1 released. Minor features and bug fixes.
27 Sep 2009
Charles 3.4 released. Major changes especially to SSL.
11 May 2009
New website launched. Follow @charlesproxy on Twitter. Say hi in San Francisco when I'm there for WWDC!
7 Mar 2009
Charles 3.3.1 released. Minor new features and bug fixes. Experimental 64 bit Windows support. Read more.
15 Feb 2009
Charles 3.3 released. Major new features. Download
24 Sep 2008
Charles Autoconfiguration add-on for Mozilla Firefox adds support for Firefox 3.1
23 Sep 2008
Charles 3.2.3 released. Minor new features and bug fixes.
6 Sep 2008
Charles 3.2.2 released. Minor new features and bug fixes.
17 Apr 2008
Charles 3.2.1 released. Minor new features and bug fixes.
24 Mar 2008
Charles 3.2 released. Major new features. Release Notes
28 Jan 2008
Charles 3.2 public beta released. Download and more information on my blog.
19 Dec 2007
Charles 3.1.4 released. Bug fixes and minor new features.
21 Nov 2007
Charles Mozilla Firefox add-on updated for compatibility with Firefox 3.0.
12 Nov 2007
Charles 3.1.3 released. Minor bug fixes, minor new features.
Chart tab now includes charts for sizes, durations and types
Request & Response can now be displayed combined on one split-panel
SSL handshake and certificate errors are now displayed in the tree
29 Aug 2007
Charles 3.1.2 released. Minor bug fixes.
27 Aug 2007
Charles 3.1.1 released. Minor bug fixes.
13 Aug 2007
Charles 3.1 released.
22 May 2007
Charles 3.0.4 released. Fixes SSL bug on Java 1.4.
14 May 2007
Charles 3.0.3 re-released. Fixes launch bug on computers that haven't used Charles before.
12 May 2007
Wcf Binaryencoded Message Inspector For Fiddler For Mac Osx
Charles 3.0.3 released. Various improvements and minor bug fixes.
23 Apr 2007
Charles 3.0.2 released. Minor bug fixes and improvements.
28 Mar 2007
Charles 3.0.1 released. Minor bug fixes.
24 Mar 2007
Charles 3.0 released. Major new features and improvements