After a huge set of changes I decided to spent my time on something less complicated and focused on the bug with Url to controller/action matching.

How unfortunate, that this wasn’t that simple. Or actually that was good - I like puzzles.

Anyway, the original issue was that when the request Url contained unpredicted query string parameters, i.e. a random one that would enforce browser to ignore the cache, current implementation would fail to match a proper controller and it’s action.

I’ve changed the original implementation from regular expression based to something more fuzzy with Url ranks.

Quick tests prooved that it was working. Unless I tried to obtain an API documentation. The situation was like that:

http://temp.uri/api/product?$skip=10$top=10$top

this should trigger a products controller with a list action. But there was another route:

http://temp.uri/api/product?format=xml

This was a GET version of the API documentation that would allow to enforce an output format without need of content-negotiation mechanism with HTTP headers. But from the algorithm point of view there was no difference between the path, and I couldn’t match query string against a regular expression as it was the previous implementation that used that approach.

Finally, the only solution for me here was to promote a controller that wasn’t a generic one. Description is generated by a special controller that uses a generic parameter of another controller being a subject of the description.

Currently I didn’t find a case that it would break something else and all other cases were working fine. We’ll see if I can figure out something to break it.