Saturday, October 31, 2015

How to change HttpClientHandler.AllowAutoRedirect

In the past I have talked about how the HttpClient is thread safe. This allows you to reuse the same HttpClient and be very efficient regarding how many ephemeral ports your application consumes.

Because the HttpClient and the HttpClientHandler both need to be thread safe, their properties become immutable after a request has been issued. If you are in a scenario where you need to change settings, such as whether or not the handler allows redirects, you will have to develop a little hack to work around the default behavior.

Below is a method where you can use reflection to set a private field and avoid the property setter from checking whether or not a request has been issued. This could cause thread safety issues, however with the current implementation of HttpCliehtHandler it is perfectly safe so long as only one thread is consume the client at a time.

HttpClientHandler Extension

public static class HttpClientHandlerExtensions
    private static readonly FieldInfo AllowAutoRedirectFieldInfo =
        typeof (HttpClientHandler).GetField(
            BindingFlags.Instance | BindingFlags.NonPublic);
    public static void SetAllowAutoRedirect(this HttpClientHandler handler, bool value)
        AllowAutoRedirectFieldInfo.SetValue(handler, value);

Unit Test

public class HttpClientHandlerExtensionsTests
    public async Task SetAllowAutoRedirectTest()
        using (var handler = new HttpClientHandler())
        using (var client = new HttpClient(handler))
            handler.AllowAutoRedirect = true;
            using (var response = await client.GetAsync(""))
            Assert.Throws<InvalidOperationException>(() =>
                handler.AllowAutoRedirect = false;


Sunday, October 25, 2015

Override Configuration via Command Line

In my previous blog posts I have talked about creating complex config objects from your app.config file, as well as how to have cascading configuration settings from multiple files. Now I want to build on that concept by taking in configuration from command line in a generic fashion that will override your other cascading settings.

Configuration Object

public class TestConfig
    public string Hello { get; set; }
    public string Goodnight { get; set; }


<?xml version="1.0" encoding="utf-8" ?>
    <add key="TestConfig.Hello" value="World" />
    <add key="TestConfig.Goodnight" value="Moon" />

Sunday, October 4, 2015

Throttles - Delay vs Semaphore

A while back I had talked about how to await an interval with a simple Throttle class that I had made. This is a very easy way to control how often you start an operation, but it does not ensure a limit to how many operations are happening at a given time.

Problem: You want to only make 5 requests per second to a remote service.

With the throttle class set to only allow one new call to start every 200 milliseconds you will only be able to start 5 new requests per second. However, if those calls take longer than two seconds to complete, then during the next second you will have 10 requests in flight at the same time.

Solution: Set your throttle to 200 millisecond and add a semaphore with a count of 5.

You can solve this problem by combining your throttle with a semaphore. This will ensure that you only start a new operation at your schedule frequency, and also that you never have more than a predetermined number in flight at the same time.

Please note that only using a semaphore would not solve the problem because if, in the same example, the calls take sub 200 milliseconds to complete then more than 5 requests will start each second.

Below is a set of helper classes (and tests) to help extend the throttle class to support this functionality within a using block.


public interface IUsableSemaphore : IDisposable
    Task<IUsableSemaphoreWrapper> WaitAsync();
public interface IUsableSemaphoreWrapper : IDisposable
    TimeSpan Elapsed { get; }
public interface IThrottle
    Task WaitAsync();

Real Time Web Analytics