1

I have a WebAPI2 web service that works on my DEV site as well as on a local staging site, but when I push to production I get a 404 error when trying to access the same services.

Here's an example of the problem ...

// production server returns 404 Error
http://my.servername.com/AppAPI/CustomerAPI/Session/4 

// local stage site works 
http://localhost:100/AppAPI/CustomerAPI/Session/4

I know that there are a number of reasons why a 404 could result. Bad routes came to mind first and seem to be the source of most 404 problems that I have seen in my research. I am using WebAPI 2 Attribute routing as seen in the controller code...

public class SessionController : ApiController
{
    [Route("CustomerAPI/Session/{id}")]
        [HttpGet]
        public string Get(int id)
        {
            return "value";
        }
}

On IIS the site that the service is located in is set up as an "Application" (AppAPI) under another site (my_servername_com).

The site structure on IIS looks like ...

* Server
  + Application Pools
  + Sites
    + my_servername_com
      + AppAPI (application)
        + bin
        - default.aspx
        - global.asax
        - web.config

As you can see, I have included a test page in the site; default.aspx. This page displays correctly on BOTH locations, so I know that the site is running and accessible and that at least the root url is correct. The fact that the services are accessible on the local site suggests to me that the Routes are also set up correctly.

http://localhost:100/AppAPI/default.aspx     -- works
http://my.servername.com/AppAPI/default.aspx -- works

Having ruled out any coding or routing issue that I could think of, it leaves me with an environment issue of some sort. I have gone through the IIS settings on both servers and they seem the same, so I am not sure what else to look at there.

My local environment (works) ...

OS: Windows 7 Professional
IIS: IIS 7 (7.5.7600.16385)
.NET Framework : .NET 4.5 (4.5.50938)

My production environment (does not work) ...

OS: Windows Web Server 2008
IIS: IIS 7 (7.0.6000.16386)
.NET Framework: .NET 4.5 (4.5.51209)

So I am left with two possibilities I think ...

  1. Networking issue? - I am not sure what the problem could be here. A little outside my wheelhouse.
  2. Some overlooked configuration?

After doing some further research I see that there are a number of issues revolving around the global.asax and WebApiConfig. As it seemed that it could be relevant I have added them here but it's important to note that this is not an MVC application.

I did not create a WebApiConfig class but created a class called "Routing.cs" that does the same thing. Which is simply to enable the attribute routing.

public class Routing
{
    public static void RegisterRoutes(HttpConfiguration config)
    {

        // enable attribute routing
        // http://www.asp.net/web-api/overview/web-api-routing-and-actions/attribute-routing-in-web-api-2
        config.MapHttpAttributeRoutes();
    }
}

And of course this is simply called in the global.asax.

    protected void Application_Start(object sender, EventArgs e)
    {
        GlobalConfiguration.Configure(Routing.RegisterRoutes);
    }

Any light that someone could shed would be helpful. I am about out of ideas. the next move would be to rewrite the services in ASMX ... ugghh ... I don't want to do that!

Thanks, G

Gary O. Stenstrom
  • 2,284
  • 9
  • 38
  • 59

2 Answers2

2

From this link:
https://weblog.west-wind.com/posts/2011/Mar/27/ASPNET-Routing-not-working-on-IIS-70

Check that you have "runAllManagedModulesForAllRequests" as true in web.config.

<system.webServer>
    <modules runAllManagedModulesForAllRequests="true">
Craig H
  • 2,001
  • 1
  • 14
  • 18
  • Holy crap! I have never heard of this before, but it seems to have resolved to problem! Thank you! – Gary O. Stenstrom Aug 12 '15 at 16:37
  • This suggestion seems to be given and accepted all over Stack Overflow, but there are a lot of things you should be aware of before running all requests through managed modules. I encourage anyone reading this answer to please do some research. – NathanAldenSr Jul 29 '16 at 15:27
0

Check order of handlers in IIS: ExtensionlessUrlHandler-Integrated-4.0 should go before StaticFile, otherwise your api call will be handled by StaticFile resulting to 404.

IIS -> Website -> Handler Mappings -> View Ordered List

You can remove StaticFile handler at all if you don't need it in your web.config:

<handlers>
  <remove name="StaticFile"/>      
</handlers>

There's also a similar thread here.

Yan Lobau
  • 1
  • 3