HttpSysRequestDelegationFeature - DelegationRule throws NullReferenceException on Dispose

[NGloreous]

Describe the bug

When disposing a DelegationRule, if the call to HttpCloseUrlGroup within UrlGroup.Dispose() fails then a NullReferenceException happens because _logger is not initialized in the constructor used by the HttpSysRequestDelegationFeature.

To Reproduce

namespace Sample
{
    public class Startup
    {
        // This method gets called by the runtime. Use this method to add services to the container.
        // For more information on how to configure your application, visit https://go.microsoft.com/fwlink/?LinkID=398940
        public void ConfigureServices(IServiceCollection services)
        {
        }

        // This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
        public void Configure(IApplicationBuilder app, IHostApplicationLifetime lifetime, IWebHostEnvironment env)
        {
            if (env.IsDevelopment())
            {
                app.UseDeveloperExceptionPage();
            }
            
            var delegator = app.ServerFeatures.Get<IServerDelegationFeature>();
            var rule = delegator.CreateDelegationRule("DefaultAppPool", "http://*:80/");
            rule.Dispose();
        }
    }
}

Exceptions (if any)

System.AggregateException: One or more errors occurred. (Value cannot be null. (Parameter 'logger'))
---> System.ArgumentNullException: Value cannot be null. (Parameter 'logger')
at Microsoft.Extensions.Logging.LoggerExtensions.Log(ILogger logger, LogLevel logLevel, EventId eventId, Exception exception, String message, Object[] args)
at Microsoft.Extensions.Logging.LoggerExtensions.LogError(ILogger logger, EventId eventId, String message, Object[] args)
at Microsoft.AspNetCore.Server.HttpSys.UrlGroup.Dispose()
at Microsoft.AspNetCore.Server.HttpSys.DelegationRule.Dispose()

[Tratcher]

if the call to HttpCloseUrlGroup within UrlGroup.Dispose() fails

Can you explain why it failed so we can reproduce the issue?

[NGloreous]

@Tratcher I'm looking into that and talking with @shirhatti. I'll file a separate issue to track as it appears to be 100% repro right now. Possibly due to a recent change in http.sys.

[NGloreous]

@Tratcher @shirhatti FYI I also filed #26989 to track the issue where this is failing in the first place. I'll try to figure out the root cause there.

[ghost]

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We will evaluate the request when we are planning the work for the next milestone. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.