Hi all,
recently there has been a twitter conversation about upgrading the new Umbraco 301 tracking facility into a fully URL Rewriting facility. I can understand why folks would think this is a good idea but I would urge everyone to consider a few things...
Firstly, there are a ton of rewrite types. The 301 logic in Umbraco handles only static rewrites. This is a 1:1 mapping, this does not contain any logic for wildcard matching, different status types, different schemas (forcing to https or http), rewrite vs redirect, etc...
The wheel for all of this has already been invented (many times now) and we don't need to re-invent this. This logic is happily baked into IIS Rewrite rules, it's supported by Microsoft and works very very well. These rules are also baked into the IIS request engine which means they occur before the request even hits ASP.Net's and Umbraco's pipeline, so by and large, it will be faster than handling this at the Umbraco request pipeline level.
That said, there is some potential to upgrading Umbraco's 301 engine to work for static rewrites (1:1). But the primary concerns of doing this is:
- People will then ask for more features such as all of the ones I mentioned above which is something we will not support in Umbraco core - because this is already invented and working well elsewhere. We don't need to add more complexity to the core to support and maintain logic that exists elsewhere.
- This functionality already exists with IIS rewrite rules and will be faster - how much faster, I don't know but I guarantee you that having this execute at the Umbraco request pipeline level will be much slower than IIS rewrites since this rule will only apply to content not found, which means it must attempt to find the content first!
- If people would want the Umbraco static rewrites to execute before content is attempted to be found - then it needs to be overhauled and changed and then we'd need to modify the db to support this type of static mapping to flag before/after.
So, one proposal is to create an IIS rewrite rule UI that folks can use to manage static mappings. Someone asked on Twitter:
so, should'nt the 301 feature have been implemented like that instead?
No... as per above, the 301 executes if no content is found so this would not work for the 301 engine since IIS rewrite rules will execute before Umbraco even knows a request is executing.
One concern with editing IIS rewrite rules was that if you add a rule, it will restart IIS. My concern would be that your web.config would become huge. This is why using an IIS Rewrite Static Map file should be used instead. We do this on Our actually right now. It's an external file that your web.config IIS rules point to which contain any number of static maps. Since external rewrite maps use the <rewriteMaps configSource="rewritemaps.config"><rewriteMaps> syntax it means the external file change will still cause a restart unless we tell the web.config to not monitor external changes.
Here's some details about rewrite maps:
- https://www.iis.net/learn/extensions/url-rewrite-module/rule-with-rewrite-map-rule-template
- https://www.iis.net/learn/extensions/url-rewrite-module/using-rewrite-maps-in-url-rewrite-module
Another alternative is to create a custom IIS Rewrite provider:
- https://www.iis.net/learn/extensions/url-rewrite-module/developing-a-custom-rewrite-provider-for-url-rewrite-module
- https://www.iis.net/learn/extensions/url-rewrite-module/using-custom-rewrite-providers-with-url-rewrite-module
Which means we could store values in any location, database, files, etc... and not worry about restarts.
All questions, comments, etc... welcome :)