Expect100Continue - A little optimization

Hackered
Wednesday, April 8, 2015
by Sean McAlinden

Over the last few years the use of shortlived tokens such as bearer tokens has become part of our normal development, an obvious side effect of the shortlived token is plenty of 401 results acting almost as a guide to the client to go and get a valid token for the call.

This process can result in a lot of bandwidth being used for sending packets that unfortunately could never reach their intended target as the call was destined for rejection.

Expect100Continue to the rescue

Expect100Continue essentially sends an Expect header to the server in order to ask whether the server will likely accept the request for POST, PUT and PATCH verbs:

If the server says it will not due to whatever reason (eg. 401 unauthorized) then the packet is not sent and the request just returns the rejection response to the client.

If the server says it is happy to accept the request, a 100-Continue response is returned and the client then sends the packet.

This behaviour benefits both the client and the server and is probably slightly greener :)

How can I set up this awesome Expect100Continue behaviour?

This behavour can be configured via the ServicePointManager (or in web.config) very easily.

Update your Global.asax to include setting the Expect100Continue property to true:

protected void Application_Start()
{
    ServicePointManager.Expect100Continue = true;
}

Done, a nice little optimization with very little effort.

Obviously before pushing any changes to server behaviour such as this you should benchmark and performance test.

Happy configuring :)