JOS.ContentSerializer 3.0 has been released!

New features

Support for more built in properties

The following properties are now supported out of the box:

  • BlockData
  • bool
  • double
  • ContentArea
  • ContentReference
  • DateTime
  • IEnumerable<ContentReference>
  • int
  • LinkItemCollection
  • PageReference
  • PageType
  • string[]
  • string SelectOne/SelectMany support.
  • Url
  • XhtmlString
  • NEW IEnumerable<string> ICollection/IList works as well
  • NEW IEnumerable<int> ICollection/IList works as well
  • NEW IEnumerable<double> ICollection/IList works as well
  • NEW IEnumerable<DateTime> ICollection/IList works as well

Easier to add support for custom properties

The old solution to add support for custom properties sucked. I've rebuilt it from scratch.

You're using the property Jos.PropertyKeyValueList on your StartPage like this.

public class StartPage : PageData  
    public virtual string Heading { get; set; }
    public virtual IEnumerable<KeyValueItem> KeyValueItems{ get; set; }

Now, if you call .ToJson on a StartPage instance you would only get the Heading property in the json output since IEnumerable<KeyValueItem> isn't handled out of the box.

    "heading" : "Where is my KeyValueItems??"

To add support for it, first create a new class that implements the IPropertyHandler<> interface

public class KeyValueItemListPropertyHandler : IPropertyHandler<IEnumerable<KeyValueItem>>  
    public object Handle(IEnumerable<KeyValueItem> value, PropertyInfo property, IContentData contentData)
        // Do whatever you want with the property here.
        return value;

Then register your class in your DI container.

public class MyConfigurationModule : IConfigurableModule  
    public void ConfigureContainer(ServiceConfigurationContext context)
    context.Services.AddSingleton<IPropertyHandler<IEnumerable<KeyValueItem>>, KeyValueItemListPropertyHandler>();

Now, if you would call .ToJson again on your StartPage instance, you would see the following output.

    "heading": "Where is my KeyValueItems??",
    "keyValueItems": [
            "key": "Some key",
            "value": "Hello there"
            "key": "Another key",
            "value": "Another value!"

Easier to extend/replace built in PropertyHandlers

Say that you, for some reason, want all strings to return "JOSEF OTTOSSON!!" instead of their actual value.

Just create a new propertyhandler for strings like this.

public class JosefStringPropertyHandler : IPropertyHandler<string>  
    public object Handle(string value, PropertyInfo property, IContentData contentData)
        return "JOSEF OTTOSSON!!";

Then swap out the default StringPropertyHandler in the DI container like this:

context.Services.AddSingleton<IPropertyHandler<string>, JosefStringPropertyHandler>();  

Custom PropertyHandler for specific property

It's possible to specify which PropertyHandler to use by adding the ContentSerializerPropertyHandlerAttribute on the desired property.
NOTE, this is currently an experimental feature, it works, but I've had no time to write tests yet, so consider it a BETA until further notice ;)

Added a __type__ property to contentarea items

I've added a property to all contentarea items named __type__.
It will be added automatically to the json output. It looks like this:

"mainContentArea": {
    "jumbotronBlock": [{
        "heading": "Wherever you meet!",
        "__type__": "JumbotronBlock"
    "teaserBlock": [{
    "heading": "Alloy Plan",
    "__type__": "TeaserBlock"

It's possible to change the property name by setting the BlockTypePropertyName(just realised that that name sucks, will fix it in the next release) property in the IContentSerializerSettings.

Breaking changes

  • All PropertyHandler interfaces are gone(IStringPropertyHandler, IStringArrayPropertyHandler and so on). Use IPropertyHandler<> instead.
  • ContentReferenceSettings has been removed, use IUrlSettings instead.
  • Added MIT License.
  • ContentAreaPropertyHandler now uses .FilteredItems instead of .Items.

As always, all code can be found on Github core - Log request/response headers

Recently we deployed a new application to our clients production environment. Their hosting partner uses a API gateway in front of the application that allows them to rate limit calls, load balance the application and stuff like that. We were told that the gateway would be "100% non intrusive" and "just work". Yeah right.

We noticed right away that our application simply did not work in the production environment. Everything worked perfectly in our own test environments but as soon as the application was deployed to production, it stopped working...
One thing I noticed was that NO headers at all were forwarded to our application...well that sucks.

So I told the hosting company "Hey, please forward all headers to and from our application and everything will start working right away".

Hah. They responded with "Sorry we can't allow all headers, you need to explicitly specify ALL the headers that you want to passthrough, so please send us a list of all the headers asap"


Anyhow, our application is an core application, we are using the authorization middleware and also a couple of other middlewares, my point is, I don't KNOW from the top of my head which headers our application use/needs, sure, I can make an educated guess and probably come close, but I will most certainly forget one or two.

Time to start coding. Since we are using core I created a simple middleware that logs all unique request/response headers that I can turn on/off in appsettings.

Actually, I created two middlewares, one responsible for saving the unique headers and one that could display the headers.
Here's the first one responsible for the "logging" part, it just saves the headers in two lists, one for the request headers and one for the response headers.

public class LogHeadersMiddleware  
    private readonly RequestDelegate next;
    public static readonly List<string> RequestHeaders = new List<string>();
    public static readonly List<string> ResponseHeaders = new List<string>();

    public LogHeadersMiddleware(RequestDelegate next)
    { = next;

    public async Task Invoke(HttpContext context)
        var uniqueRequestHeaders = context.Request.Headers
            .Where(x => RequestHeaders.All(r => r != x.Key))
            .Select(x => x.Key);

        var uniqueResponseHeaders = context.Response.Headers
            .Where(x => ResponseHeaders.All(r => r != x.Key))
            .Select(x => x.Key);

Since I made the lists public I can then access them in my other middleware responsible for displaying the headers.

In my startup.cs file I register the logging middleware like this, I also map the url /show-headers to the ShowHeadersMiddleware

public void Configure(  
            IApplicationBuilder app, 
            IHostingEnvironment env, 
            ILoggerFactory loggerFactory,
            IOptions<ApplicationSettings> applicationOptions) 
    // Appsetting that toggles the logheaders middleware.
        // Extension method that enables the logging middleware
        app.Map("/show-headers", ShowHeaders);

private static void ShowHeaders(IApplicationBuilder app)  
    app.Run(async context => {
        var requestHeaders = string.Join("<br/>", LogHeadersMiddleware.RequestHeaders.OrderBy(x => x));
        var responseHeaders = string.Join("<br />", LogHeadersMiddleware.ResponseHeaders.OrderBy(x => x));
        var output = $"<h2>Unique request headers</h2>{requestHeaders} <h2>Unique response headers</h2> {responseHeaders}";
        context.Response.ContentType = "text/html";
        await context.Response.WriteAsync(output);

I then enabled the logging in our test environment and had our QA-people browse around in one of our other applications that uses the API so I could get a list of all the unique headers. I then sent the list to the hosting provider and sure started working right away.