Why are the Rewrite rules all marked internal?

[xantari]

I'm attempting to interogate the Rewrite rules, but all the rewrite rules are marked as internal so I can't actually cast to that type.

https://github.com/dotnet/aspnetcore/blob/a23dd41428f2be93435b730ff0fcff05bf196c93/src/Middleware/Rewrite/src/RedirectRule.cs

   RewriteOptions options;
...
...
                foreach(var rule in options.Rules)
                {
                    //switch(rule)
                    //{
                    //    case RewriteRule itm: {

                    //    }
                    //}
                }

In the above you cannot interrogate the options.Rules collection, they are all type of IRule, and am unable to cast them to RewriteRule because the class is internal.

How to iterate through the rules collection?

[SteveSandersonMS]

If you could give more information about what you're trying to do (for example, what you intend to do with the information inside the rewrite rules) we might be able to offer more suggestions.

@jkotalik I guess it's clear the internal are intentional on the rule types. The rewriter rules don't appear in ApiExplorer or any equivalent do they?

[xantari]

So the scenario is this:

We have a headless CMS (Kentico Kontent), and all the rewrite rules are defined in that headless CMS that our marketing department controls for the content they write.

Upon application startup we load all those rules into the application using the rewrite middleware. We also cache that entire list of Rewrite rules into the IMemoryCache (could be distributed cache too if we wanted, assuming they are serializable that way).

The problem is the rewrite middleware does not support modification to the rewrite rule collection (open issue #16658)

Therefore what we do is we have piggy backed off of UseStatusCodePagesWithReExecute instead. And when it goes to our customer error controller, we see if it is a 404 (since it may be a new redirect rule that was added AFTER the application has started).

So we then look at the latest rewrite rule collection (this collection has been modified since the application has started, but #16658 issue prevents us from making those collection modifications take effect in the middleware).

So we are stuck with evaluating the incoming URL in our custom 404 error page and going through the entire collection of rewrite rules to see if the incoming URL matches that.

At least that is what we hoped to do.

All of this would be unnecessary if #16658 was addressed.

At any rate, what we are doing now since we can't interrogate the RegEx match info in the RedirectRule cause it's marked as internal, is we made a clone of that class (minus the ApplyRule function) to see if there is a RegEx match on the incoming URL and bring our customers to the proper place.

I hope this all makes sense... I was just hoping to re-use your class since we are already maintaining the collection of Rewrite rules (which unfortunately the middleware doesn't take advantage of the latest collection due to #16658).

[Tratcher]

It might be easier to fix #16658 and build a local copy until the fix is available in the next release. Want to help with the fix?

[xantari]

I could try take a look at some point, but it would be awhile before i could get to it. I'm not sure how you would unit test something like this though to test for the thread safety issues you had mentioned in #16658