MonoRail’s SmartDispatcherController will automatically bind controller method parameters to request parameters. So the arg0 and arg1 parameters in the method below -

public void DoSomething(string arg0, int arg1)
{
...
}

will have the values castle and 5 respectively when the request is constructed like

/SomeController/DoSomething.rails?arg0=castle&arg1=5.

While this is certainly a useful feature, it’s important to remember that any item in the Request.Params collection is a candidate for binding. At work, my team and I recently ran into a problem where this behavior resulted in some unexpected exceptions.

The site running MonoRail has some classic ASP that’s being phased out, but is still accessed during a visitor’s session. During the ASP flow, some session cookies are set. One of these cookies happens to share the name of a parameter in one of our controller methods. When this controller action was hit, the values from the query string param and the session cookie were both used during parameter binding.

Our logs showed that the requests were coming in correctly and we couldn’t reproduce the exception by recreating the request. Fortunately we had a dump of the request param values that were throwing the exceptions. We noticed the same param key was set in both ASP and MonoRail handled requests. This observation led one of my developers to speculate about cookie binding. A quick look at the Castle sources confirmed that suspicion. After a quick parameter name change, the exceptions stopped.