Why won't this route match

Question

I'm having some trouble getting routes to match.

I am using base-32 encoded int's as short links to slideshows in a web app. There are 5 different versions of each slideshow, and I am using an initial letter to distinguish between each version.

The routes always match, except when the first character of the base-32 encoded int is the same as the character designating the slideshow version. This anomaly exists for all 5 prefix letters: n, f, c, x, and h.

What about the first two characters being the same makes these routes not match? I'm at a loss to understand what's going on here (when the routes don't match, they simply fall through to the default).

Route Matches (/na0):

Route Doesn't Match (/nn0):

Route Matches (/nfg):

Route Doesn't Match (/ffg):

I'm boggled. Here's the routing code, in case it isn't clear in the RouteDebug tables in the screenshots:

        routes.MapRoute(
            "NonBrandedSlideshow",
            "n{id}",
            MVC.Slideshow.NonBranded(), null,
            new { id = Settings.Base32Regex }
        );

        routes.MapRoute(
            "FullSlideshow",
            "f{id}",
            MVC.Slideshow.Full(), null,
            new { id = Settings.Base32Regex }
        );

        routes.MapRoute(
            "CompactSlideshow",
            "c{id}",
            MVC.Slideshow.Compact(), null,
            new { id = Settings.Base32Regex }
        );

        routes.MapRoute(
            "FlexibleSlideshow",
            "x{id}",
            MVC.Slideshow.Flexible(), null,
            new { id = Settings.Base32Regex }
        );

        routes.MapRoute(
            "Html5Slideshow",
            "h{id}",
            MVC.Slideshow.NonBrandedHtml5(), null,
            new { id = Settings.Base32Regex }
        );

I should note here that I am using T4MVC (see section 2.2.5), and these MapRoute methods are extensions added by T4MVC. The MapRoute methods I am using are equivalent to the standard methods, and I have tried using the non-T4MVC MapRoute method with the same result:

        routes.MapRoute(
            "Html5Slideshow",
            "h{id}",
            new { controller = "Slideshow", action = "NonBrandedHtml5" },
            new { id = Settings.Base32Regex }
        );

Here is the Base32Regex, though I have tried it with and without this constraint (the Base32 implementation I am using will assume I and O are 1 and 0, for example).

public static partial class Settings
{
    public static string Base32Regex
    {
        get { return @"[0-9ABCDEFGHJKMNPQRSTVWXYZ]+"; }
    }
}

Answer 1

This is a known bug in ASP.NET Routing, see this answer for an explication and a workaround. In short, using literal sub-segments does not work very well.

Answer 2

Well, I am just as boggled. I performed some other tests and as far as I can see, this has to be some bug in the way the routes are checked when the constant before the route parameter has the same repeated character. Some other boggling examples:

"nn{id}"
route matches (/nna0)
route doesn't match (/nnn0)

"nnn{id}"
route matches (/nnna0)
route doesn't match (/nnnn0)

as soon as i make the constant not repeat the same character, all is well

"mn{id}"
route matches (/mna0)
route matches (/mnn0)
route matches (/mnmn)

This may not be exactly what you are looking for. But given the oddity of the situation, it was the only thing I could come up with. Add the constant to the constraint and remove it from the url. Then in your controller (this is the part I didn't like) you will need to remove that constant from the id parameter. Hope this works, or at the least help spark another solution.

routes.MapRoute(
    "NonBrandedSlideshow",
    "{id}",
    MVC.Slideshow.NonBranded(), null,
    new { id = "n"+Settings.Base32Regex }
);

UPDATE:

I guess this is a known issue, thanks @max-toro

Answer 3

I haven't had much success getting routes to match with prefixing a constant to a route parameter like "const{param}". Have you tried using your prefix as a complete route segment, like "const/{param}"? Would that meet your requirements?

routes.MapRoute(

    "NonBrandedSlideshow",
    "n/{id}",
    MVC.Slideshow.NonBranded(), null,
    new { id = Settings.Base32Regex }
);

routes.MapRoute(
    "FullSlideshow",
    "f/{id}",
    MVC.Slideshow.Full(), null,
    new { id = Settings.Base32Regex }
);

...etc?

Update after comment #1

Understood. The only other thing I can think of to try would involve making the id param a catchall parameter. See if that works:

routes.MapRoute(

    "NonBrandedSlideshow",
    "n{*id}",
    MVC.Slideshow.NonBranded(), null,
    new { id = Settings.Base32Regex }
);

routes.MapRoute(
    "FullSlideshow",
    "f{*id}",
    MVC.Slideshow.Full(), null,
    new { id = Settings.Base32Regex }
);

However, these routes should be registered late, so that the controller doesn't end up routing any URL prefixed with n, f, etc. to these controller actions.

Answer 4

have you tried matching them without the route contraint on the end?

EDIT: sorry for half an answer got interrupted

you need to try this for a route constraint

     routes.MapRoute(
            "NSlideshow",
            "{id}",
            new { controller = "SlideShow", action = "N", id = UrlParameter.Optional },
            new
            {
                id = @"^[n]{1}[0-9ABCDEFGHJKMNPQRSTVWXYZ]+"
            }
        );

     routes.MapRoute(
            "GSlideshow",
            "{id}",
            new { controller = "SlideShow", action = "G", id = UrlParameter.Optional },
            new
            {
                id = @"^[g]{1}[0-9ABCDEFGHJKMNPQRSTVWXYZ]+"
            }
        );

rinse and repeat for each case, in your action method strip the first character off the front of the id

Answer 5

This is a workaround. A weird one, I think...

As you routing rules are pretty simple, you can create a custom ControllerFactory and check the url. if the url matches your way, you can define which controller and action to use, and set the id paramenter based on the url. If not, just leave the regular behavior.

I know, it won't make use of the out-of-the-box routing, but as it doesn't work... The good news is as soon as it's fixed you can update the routes, remove the custom ControllerFactory and continue without the workaround.