Thursday, April 30, 2015

Short Circuiting Requests in OWIN Middleware

In earlier posts I've looked at writting and packaging OWIN middleware that does something to requests on thier way in and to the response on its way out. This time around I will show how middleware can choose to short circuit the pipeline and just return a response immediately.


Do not call next, and fill in the "owin.ResponseBody" environment key.


Usually one middleware calls the next and that is how the pipeline is executed and how different pieces of middleware gets to each do their thing. At the end of the pipeline is the application where you do whatever application logic to handle the request. There are situations, though, where it makes sense for requests to not even reaching the application logic:
  • Requests from unpaying customers could be throttled to some low rate
  • Requests from certain IPs could be blocked
  • Requests without valid authentication tokens could be turned away with a 401 status
  • Some endpoint are not for application use - like monitoring endpoints

Build a Monitor Middleware

Lets take a look at building a middleware that provides a monitoring endpoint. It will listen on the path "/_monitor" and will respond with a small json object containing the version of the deployed software.

Once again I implement the middleware using the OWIN Midfunc - which we can think of as a curried function taking first the next piece of middleware in the pipeline and then the OWIN environment dictionary.
To implement the monitoring endpoint I look up the request path in the environment dictionary and decide if it is a monitoring path. If it is I write a simple json string to the response body, set the content type header and return. On the other hand if it is not a monitoring endpoint I just pass the environment into the next middleware in the pipeline.
Here is the code:

Tuesday, April 7, 2015

Packaging OWIN Middleware

Following on from the last post about building OWIN middleware directly as functions this post shows how to package such middleware up in an easy to consume package. Doing so is quite easy, so this post is quite short.

The request logging middleware developed in the last post looks like this:

To use this application developers will have to add that function to their OWIN pipeline. Doing so in pure OWIN, without resorting to APIs specific to a given server implementation, is a matter of calling the build function with the middleware function. The server implementation is responsible for providing the build function.

Using the ASP.NET 5 API for obtaining an OWIN build function and assuming the requestLoggingMiddleware is in scope adding middleware through the build function looks like this:

Nice and simple. What we might add on top of this is a simple extension method to the build function:

turning the code for adding the middleware to the pipeline into this:

The advantage of this is that
  • the requestLoggingMiddleware variable need not be in scope in the application code
  • the extension method provides a convenient place for application startup code to pass in parameters to the middleware - like say logging configuration parameters or whatever else might be relevant
  • the extension method returns the build function allowing application code a convenient way of chaining pipeline setup

Now sharing the middleware a across a number of services (and teams) is a matter of sharing the class above through e.g. NuGet.