To explain the function of this module and some of the design choices we made, we’ll first explain how 404 page handling works in DNN.
DNN has some built in 404 handling, but this also has some limitations.
The DNN Core functionality is mainly targeted at the situation where the URL of a page changes.
When you change the URL of a DNN page, the old URL remains in the TabURLs table in the database.
This helps to create redirects when you change the URL of a page, but it does not help for deleted pages as in that case the Tab URL is also removed.
This also does not cover URLs that never existed or static files (images, documents).
Moved pages are also not always correctly redirected by DNN.
Also the built in DNN redirect to the 404 page, only works for root pages.
URLs that point to higher levels will be severed as the first page up the tree.
This is "by design" because in DNN, detail-URLs of modules are handled by the module itself.
The core does not know what detail URLs (could) exist for a module on the page.
So for this page structure Example:
---- Product 1
---- Product 2
---- Product 3
---- Product 4
When a user requests the following URLs:
The user will be shown the DNN 404 page.
The user will see the products page and not the DNN 404 page.
This is why our HttpModule is needed for redirects.
When you create a redirect for the “nothing” page in the second example, the HTTP module will do the redirect before DNN tries to serve it (as it would show you to the “products” page).
FYI; there is currently no way to force DNN show the 404 page for pages other than the root level.
To overcome this we introduced the "Force 404" list