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:
this should trigger a products controller with a list action. But there was another route:
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.