DNN - Why don't Nonexistent Child Pages Return 404

 

Problem 

Often users come across the situation where they request an invalid page on their site and find that the URL doesn't return a 404 when they expected.


For example, let's assume this is a valid page:

example.com/valid-page

If a user requests the URL:

example.com/valid-page/invalid-page

and there is no child page of 'invalid page', the user might expect a 404 error to be shown. However, with the Advanced URL Management (AUM) provider, this is not the case. Instead, another page at the site that has valid content is shown.

 

Answer

This is not a bug, it is an expected behavior. The reason is in how the module handles URLs for third-party modules that display content based on the URL. If we take the Blog module, for example, then this is what the 'standard' blog page might look like:

example.com/blog

If a user views this URL, a summary of all blog posts will be displayed.

Later, the user requests a specific blog post, the user sees a URL like this:

example.com/blog/entryid/23/the-blog-post-title

The /blog/ part of the path specifies which DNN page to use. The remainder of the path /entryid/22/the-blog-post-title is determined by the URL Master module to be specific to some other module on that page, so it is rewritten as part of the URL. The end result, the rewritten URL looks like this:

example.com/default.aspx?tabid=xx&entryid=32&the-blog-post-title

This is because the module takes whatever comes after the best-match on page path, and converts it into a query string.

So when you request a URL like this: example.com/valid-page/invalid-page, the /valid-page/ part of the path is matched to a DNN page, and the rest is assumed to be part of the query string for that page. The rewritten URL will look like this:

example.com/default.aspx?tabid=xx&invalid-page

Because the AUM provider does not know which modules are on a DNN page and it cannot know in advance what type of query string values to expect, it passes through anything after the DNN page match as a query string. In other words, a non-existent child page does not return a 404 page because there's no way of the module knowing if that part of the URL is an invalid page, or it was information required by a module on the page.

If a user deletes a child page, the best practice is to set up a redirect for that 'old' URL. If a page is deleted and left in the recycle bin (a soft delete), then AUM can detect the delete and return a 301 or 404 status (depending on settings). If a hard-delete of the page is performed, then the user simply should set-up a redirect to catch the old value and redirects the page to someplace. On the other hand, if there is an external link that has been set to a non-existing page, then the URL should be captured with a redirect.

 

Comments

0 comments

Please sign in to leave a comment.