HttpConnection Limit in .NET

Does your .NET application need to make a large number of HTTP requests concurrently? Be warned that the amount of simultaneous HTTP connections might get throttled by the .NET Framework. Often this can be a good thing, as it is a restriction that is designed to help protect an application from harming a larger system.

Don't worry, you can easily raise the connection limit by adding a simple Connection Management Section to your app.config or web.config:

<configuration>

  <system.net>

    <connectionManagement>

      <add address="*" maxconnection="10000" />

    </connectionManagement>

  </system.net>

</configuration>

Enjoy,
Tom

Why you should use more HTTP.

I am a big fan of Ayende Rahien. He leads Hibernating Rhinos, develops RavenDB, and contributes to NHibernate. Oh, and he is an avid blogger that puts my release schedule to shame.

Ayende recently blogged about over the wire protocol design, and I wanted to echo opinion on this subject!

How to actually send it?

As applications become more complicated they frequently need to communicate with remote resources. So how should your applications talk to each other? If you had not figured it out already: I suggest HTTP!

Why use HTTP?

Here are just a few very small reasons that I love working with HTTP:

• It is supported by every language.
• It is supported by every platform.
• It is supported by every device.
• It has standards for authorization.
• It has standards for encryption.
• It has standard response codes.
• There are amazing tools for it.
• There are more amazing tools for it.
• There are still more amazing tools for it.

...need I go on?

Why NOT use HTTP?

I always look to successful companies for inspiration with technology. If you are making a store front, I suggest you look at Amazon or Newegg. If you are creating social media features, I suggest you look at Facebook or Twitter. If you are designing APIs, I suggest you look at Google. Do you know what Larry Page did not say after Google made it big? "Man, I really wish that we hadn't invested so heavily in all of that web stuff!"

Okay seriously, depending on your application there may be reasons not to use HTTP as your communication protocol. However for the vast majority of applications I think it will do the job, and I strongly urge you to consider using it instead of reinventing the wheel again.

Just my two cents,
Tom

Web API - Bad Request when Model State is Invalid

When you using Web API, would you like to always return a 400 (bad request) response whenever the model state is invalid? It is easy, just add the following filter attribute to your global list:

[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method, 

    AllowMultiple = false, 

    Inherited = true)]

public class InvalidModelStateFilterAttribute : ActionFilterAttribute

{

    public override void OnActionExecuting(HttpActionContext actionContext)

    {

        if (!actionContext.ModelState.IsValid)

        {

            actionContext.Response = actionContext.Request.CreateErrorResponse(

                HttpStatusCode.BadRequest, 

                actionContext.ModelState);

        }

    }

}

Enjoy,
Tom

Basic and Digest mixed authentication with WebAPI

In my last post I talked about using both Basic and Digest authentication with WebAPI, but not at the same time. So what do you do when you want to used mixed authentication with both?

In principal you can support both Basic and Digest authentication at the same time, but your server has to issue the 401 challenge with Digest. This is because basic requires no token or server information to authenticate, where as digest requires a nonce from the server.

I have updated Rick's Basic authentication and Badri's Digest authentication implementation to work together as a pair of AuthorizationFilterAttributes. Here is the source:

• DigestAuthDemo on GitHub

public static class WebApiConfig

{

    public static void Register(HttpConfiguration config)

    {

        config.Filters.Add(new BasicAuthorizationFilterAttribute(false));

        config.Filters.Add(new DigestAuthorizationFilterAttribute());

        config.MapHttpAttributeRoutes();

        config.Routes.MapHttpRoute(

            "DefaultApi",

            "{controller}/{id}",

            new { controller = "data", id = RouteParameter.Optional }

        );

    }

}

Enjoy,
Tom

WebAPI and Chrome Authentication Types

Google Chrome supports four HTTP authentication types:

1. Basic
2. Digest
3. NTLM
4. Negotiate

ASP.NET WebAPI has AuthorizationFilterAttributes which can be used to implement both Authentication and Authorization for your APIs. If you want to use Basic or Digest authentication, there are already several open source implementations available to help you out!

• Rick Strahl - WebAPI Basic Authentication Authorization Filter
• Badri - Digest Authentication with ASP.NET Web API

Do you need to used mixed authentication and support both Basic and Digest?
If so, be sure to check out my next blog post...

Enjoy,
Tom

Python 2.6 and HTTP Basic Authentication

I recently encountered an issue where adding basic authentication to some HTTP calls was breaking a Python application.

Come to find out there is a bug in Python 2.6 that appends a newline character to base 64 encoded strings. That newline character then causes your HTTP request to be malformed, so that the body does not match the content length. When consuming these malformed requests in an ASP.NET sever the body content would cut off early, and in the case of JSON content this made it so that the JSON string was incomplete and could not be parsed.

So what's the fix? You can either update Python, or fix your string after encoding.

Enjoy,
Tom