Bug Report: HTTP 503 on Windows Revisited - v3 edition - with workaround!

I’ve seen a few posts on this one, and ran into it this morning and lost a bunch of time on it… so you don’t have to relive my pain:

Browsing to fails with a 503.

It appears that eventstore now checks to see if there is an appropriate acl on the port and creates one if not (you’ll notice a tell-tale UAC dialog pop up asking if you want to run Network Command Shell).

The problem I ran into is that eventstore doesn’t consider http://+:2113/ (the url I used) a match for (the url it creates a rule for - even if the wildcard rule is there).

You are most likely to run into this if you followed the getting started advice and created the wildcard rule.

Until the start-up check is fixed, the solution is to delete the original rule - netsh http delete urlacl url=http://+:2113/ - It’s also worth checking for duplicates with net http show urlacl - if there are any the whole thing fails silently, and worse, from the logs it all looks ok.

I recommend eventstore attempts to open the port without checking the rules, and only if this fails with the expected exception should it offer to create the rule.

Note that ANY duplicate rules seem to cause a failure, even ones on other ports.

Hi James,

That’s exactly what we do: https://github.com/EventStore/EventStore/blob/dev/src/EventStore.Transport.Http/Server/HttpAsyncServer.cs#L49 - we only try to add a rule if binding fails. It may be that there could be other reasons for failure however.



Odd - well I can recreate consistently by created the wildcard rule before running eventstore… it doesn’t see it and it creates the rule. Note you can delete the wildcard rule even while eventstore is running and it fixes things immediately.

I wonder if the binding actually doesn’t fail with an exception in the event of the duplicate rule - but just doesn’t work!