How to make Skybrud Redirect work along with a Custom 404 handler

[kikodev714]

Which version of Skybrud Redirects are you using? (Please write the exact version, example: 4.0.8)

4.0.8

Which Umbraco version are you using? (Please write the exact version, example: 10.1.0)

Umbraco 10.1.0

Question

I wonder if you can help me out with an issue. We are running Umbraco 10, USkinned 3 and Skybrud 4 to handle our custom redirects.

With all this setup, we we were able to cover redirects from old urls including those that are using file extensions (.asp, aspx etc...)

What it cannot cover though are old urls with extensions that are not defined in Skybrud redirects.

Example: If I go to "website.com/home/samplepage.aspx" and it's not in Skybrud, it will result to a .net default "unfriendly" URL page. This is because the built in mechanism is using IContentLastChanceFinder which does not work for URLs with filename extensions

Now, to mitigate that, we've added a simple custom 404 handler in startup

app.UseStatusCodePagesWithReExecute("/friendly-404-page/")

However, this is now causing a conflict with the Skybrud redirect entries. If an entry in Skybrud has filename extensions, the 404 handler kicks in and doesn't redirect the page.

I wonder if there's a way in Skybrud where we could influence the order so our custom 404 handler is called last or if there's another way we could handle this better.

[abjerner]

Hi @kikodev714

ASP.NET Core's behavior is a bit weird when using the UseStatusCodePagesWithReExecute method. The redirects package has a custom middleware that relies on getting the URI of the inbound request, and then checking whether a redirect exists for that URI.

When running the site via either dotnet watch or from Visual Studio, the URI passed to the custom middleware is the URI as requested by the user - eg. https://website.com/home/samplepage.aspx. So here everything works fine.

On the other hand, when running via either dotnet run or on a full IIS server, the URI passed to the custom middleware is instead the URI of the error page - eg. https://website.com/friendly-404-page/. This way the redirects package is unable to find any redirects because it tries to find a redirect matching the URI of the error page.

I'm pretty sure that I've tested using the UseStatusCodePagesWithReExecute method in the past, but I've probably only done so running the site from Visual Studio, and therefore not spotted any issues.

As of now, I'm not entirely sure why the behavior differs depending on how you're running the site, so at the moment, I don't have a solution to solve this.

[kikodev714]

Hello @abjerner

Thank you for the response.

Actually, the issue that I just describe can be replicated from my local machine running Visual Studio. Perhaps there's a setting that I'm missing? I wonder if you can replicate this behavior on your end too.

I wonder if Skybrud redirects can be extended so we can influence the order when it's called. Perhaps if we can call it first and then my UseStatusCodePagesWithReExecute, it would work?

Our ultimate goal is this. If a page with extension (e.ge: https://website.com/home/samplepage.aspx) is in in Skybrud, it should redirect properly. If not, then it should show a friendly 404 page.

[abjerner]

Hi @kikodev714

I've had a look the code, and it turns out that if the URL is rewritten as it happened in some cases, ASP.NET Core exposes a IStatusCodeReExecuteFeature through request.HttpContext.Features.Get<IStatusCodeReExecuteFeature>(), which then has the original URL. I've just pushed a new release which should then hopefully fix your issue.

https://github.com/skybrud/Skybrud.Umbraco.Redirects/releases/tag/v4.0.14

Can you confirm whether this helps or not?

[kikodev714]

Thanks @abjerner I will try the updated version on my end and will let you know.