Get Help:Ask a Question in our Forums|Report a Bug|More Help Resources
Last post Jun 16, 2012 11:53 AM by mdesousa
Jun 13, 2012 06:33 PM|LINK
Hi, I'm running on the MVC 4 Beta bits, and I'm running into an issue.
In my development environment, the Web Api framework works very well, but when I deploy to our staging environment it just returns a 503 response. Any ideas of what could be causing this, or how to troubleshoot?
I've also been trying to get the source code for the beta, but the code in
https://git01.codeplex.com/aspnetwebstack.git has its initial commit on March 11, and the binaries for January 26. Is the actual source code for the beta version available somewhere else?
Jun 13, 2012 07:36 PM|LINK
Well I have had the same issue. How I overcame this problem is that build it in release (not in debug) and then deploy the release version build.
Hope it helps,
Jun 14, 2012 01:59 PM|LINK
Thanks for your suggestion Kemal. I tried doing a release build, but unfortunately that didn't help.
I also just tried upgrading my code and installing the Web Api RC on this environment, but I am still getting the same result.
This may be a security issue.... this is a locked down environment with no access to the Internet and restricted access. However, there are no exceptions during service start-up (it's Self-Hosted), and all I can see is that the request returns 503 with no
Any other suggestions on how to troubleshoot would be appreciated.
Jun 16, 2012 11:53 AM|LINK
I finally found the problem. This was an issue caused by redudant http acls on the server. We used to have one acl for each controller supported by our service, like this:
After upgrading from the WCF Web Api framework to the new ASP.Net Web Api, we stopped adding routes for each controller. Instead, we create an HttpSelfHostServer with an address of
http://server/webapi. To do this, a new acl was added:
This allows the service to start, but any requests to the controllers (which kept the same URLs) now return a 503 because multiple ACLs match that URL.
The solution was to remove the original 2 acls, since they are not required anymore.
It would be nice if the Web API framework could catch this and trace details about the underlying exception... I was never able to find anything the windows event logs.