HttpSysRequestDelegationFeature - HttpSysException when creating two delegation rules for the same queue but different url prefixes

[NGloreous]

Describe the bug

Using the new delegate request feature create two delegation rules for the same queue name but different url prefixes. This results in an HttpSysException.

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>();
            delegator.CreateDelegationRule("DefaultAppPool", "http://*:80/");
            delegator.CreateDelegationRule("DefaultAppPool", "http://*:443/");
        }
    }
}

Exceptions (if any)

Microsoft.AspNetCore.Server.HttpSys.HttpSysException (183): Cannot create a file when that file already exists.
         at Microsoft.AspNetCore.Server.HttpSys.UrlGroup.SetProperty(HTTP_SERVER_PROPERTY property, IntPtr info, UInt32 infosize, Boolean throwOnError)
         at Microsoft.AspNetCore.Server.HttpSys.UrlGroup.SetDelegationProperty(RequestQueue destination)
         at Microsoft.AspNetCore.Server.HttpSys.ServerDelegationPropertyFeature.CreateDelegationRule(String queueName, String uri)

Further technical details

Targeting ASP.NET Core 5.0.0-rc.1.20425.11

.NET SDK (reflecting any global.json):
 Version:   5.0.100-rc.1.20426.10
 Commit:    e6cd5e783a

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.17763
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\5.0.100-rc.1.20426.10\

Host (useful for support):
  Version: 5.0.0-rc.1.20425.18
  Commit:  55ab8ce696

.NET SDKs installed:
  3.1.401 [C:\Program Files\dotnet\sdk]
  5.0.100-rc.1.20426.10 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.All 2.1.21 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.21 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.0-rc.1.20425.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.21 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.0-rc.1.20425.18 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 3.1.7 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 5.0.0-rc.1.20425.5 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

[Tratcher]

Using the new delegate request feature create two delegation rules for the same queue name but different url prefixes.

The url prefix is only used to locate the right url group, the value is not used as part of the delegation. In this case it sounds like both prefixes are part of the same url group?

[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.

[NGloreous]

@Tratcher you are correct both prefixes are part of the same group and registering both is unnecessary (which wasn't clear to me at first). This isn't a blocker at all but handling this case better with either a no-op or a better exception with a clear error message would be great.

[shirhatti]

The server doesn't track all delegation rule, we've delegated (pun intended 😅) that responsibility to the user. I assume this failure is benign since the delegation property has already been set.

Assuming that works (I'm about to try), I'll swallow the exception. If that fails, I'll look at a better exception message

[shirhatti]

@Tratcher and I decided not to do anything here. The ERROR_ALREADY_EXISTS error is sufficient