Why does HttpListener "conflict with an existing registration" when listening to a Strong Wildcard (http://+:port) http.sys/urlacl binding?

Question

Imagine that an elevated user (eg. installer) configures a URL reservation:

 netsh http add urlacl url="https://+:8105/" user="SVCACCOUNT" listen=yes

Now when Owin started (running under SVCACCOUNT), the following error results:

System.Net.HttpListenerException: Failed to listen on prefix 'http://+:8105/' because it conflicts with an existing registration on the machine.
   at System.Net.HttpListener.AddAllPrefixes()
   at System.Net.HttpListener.Start()
   at Microsoft.Owin.Host.HttpListener.OwinHttpListener.Start(..)
   at Microsoft.Owin.Host.HttpListener.OwinServerFactory.Create(..)
...
at Microsoft.Owin.Hosting.Engine.HostingEngine.Start(StartContext context)

And the Owin 'entry' point:

WebApp.Start("http://+:8105", ..)

---

During creation of the question, I discovered that a registration of http://*:8105 and an Owin / HttpListener URL of the same "worked".

• What prevents HttpListener (and thus Owin) from using the registrations previously taken with a Strong Wildcard?

• Why does using * (a "weak wildcard") in both registration and binding allow a listener to start? (Using a "strong wildcard" is throwing the error above; removing the registration entirely will cause the listener to fail with an "Access is denied" due to limited account access.)

Where is this documented, and what 'ramifications' does the fix of switching from a strong to weak wildcard have? And why does this fix even work? From the many times a related question has been asked (often without a good answer), it appears that + "probably worked" in the past and/or on different systems or configurations: what changed?

(I've found scattered documentation on http.sys configuration, such as Host-Specifier Categories although still no clear explanation for the 'conflicting registration'.)

---

If the registrations are deleted per System.Net.HttpListenerException: Failed to listen on prefix 'http://localhost:8080 the Owin service starts successfully. However I believe that this then requires higher elevations to listen to the ports.

This is not a duplicate of "Owin self-host - Failed to listen on prefix 'http://localhost:12345/' because it conflicts with an existing registration on the machine" because the question only arises when there is a URL reservation defined: also, there is no other process listening, as confirmed via netstat.

Questions like Self hosted OWIN and urlacl make me believe it's either a permission issue or something trivial.. eg., how does http://+:port differ from http://*:port? (And no, using 'EVERYONE' for the urlacl does not resolve the issue.)

The comment in "Running self-hosted OWIN Web API under non-admin account" might be relevant - pertains to + vs * .. and a general lack of clarification.

Answer 1

- What prevents HttpListener (and thus Owin) from using the registrations previously taken with a Strong Wildcard?

Maybe the problem was you are registering HTTPS protocol:

netsh http add urlacl url="https://+:8105/" user="SVCACCOUNT" listen=yes

And then you are using the HTTP protocol in the code:

WebApp.Start("http://+:8105", ..)

-Why does using * (a "weak wildcard") in both registration and binding allow a listener to start?

The difference between * and + wildcards are the * include the void element and the + force to exist at least 1 character. I don't known the execution difference, but is probably a tiny almost imperceptible.