.Net 6 with Ocelot 18 returns error 404 when navigating to an URL of the gateway after publish in IIS

2 min read 05-10-2024
.Net 6 with Ocelot 18 returns error 404 when navigating to an URL of the gateway after publish in IIS


.NET 6 with Ocelot 18: Troubleshooting 404 Errors After IIS Deployment

Problem: You've built a .NET 6 API Gateway using Ocelot 18 and everything works flawlessly in development. But after deploying your application to IIS, you encounter frustrating 404 Not Found errors when accessing your gateway's URLs.

Rephrased: Imagine you've built a central hub (the gateway) that directs traffic to different services (like a shopping cart or a user profile). Everything works fine when you're testing it locally, but once you deploy it to a real-world server, it can't find any of the services it's supposed to direct traffic to.

Scenario & Original Code:

Let's consider a simple example:

// Ocelot configuration in Program.cs
builder.Services.AddOcelot(Configuration.GetSection("Ocelot")).AddSingleton(sp => Configuration.GetSection("Ocelot"));

// Sample Ocelot configuration in appsettings.json
{
  "Ocelot": {
    "GlobalConfiguration": {
      "BaseUrl": "http://localhost:5000"
    },
    "ReRoutes": [
      {
        "DownstreamPathTemplate": "/api/products/{productId}",
        "DownstreamScheme": "http",
        "DownstreamHostAndPorts": [
          {
            "Host": "localhost",
            "Port": 5001
          }
        ],
        "UpstreamPathTemplate": "/products/{productId}",
        "UpstreamHttpMethod": [ "GET", "POST", "PUT", "DELETE" ]
      }
    ]
  }
}

Analysis & Clarification:

The issue often stems from how Ocelot handles URLs in development vs. deployment. In development, Ocelot uses the configured BaseUrl (http://localhost:5000 in our example) and its relative paths work seamlessly. However, in IIS, Ocelot is usually deployed within a virtual directory. This can lead to mismatches in the URLs that Ocelot expects and the URLs that are actually accessed by your users.

Key Troubleshooting Steps:

  1. Check Your BaseUrl: Ensure that the BaseUrl in your appsettings.json reflects the actual base URL of your Ocelot application when deployed to IIS. This should be the URL where your gateway is accessible (e.g., https://yourdomain.com/api-gateway).

  2. Verify Virtual Directory Configuration: If you're using a virtual directory in IIS, the BaseUrl needs to include the virtual directory path. For example, if your virtual directory is api-gateway, your BaseUrl should be https://yourdomain.com/api-gateway.

  3. Test with Absolute URLs: In Ocelot's configuration, use absolute URLs instead of relative ones for DownstreamHostAndPorts. This ensures that Ocelot knows the exact URL of the target service, regardless of its location:

    "DownstreamHostAndPorts": [
       {
         "Host": "http://your-product-service.com",
         "Port": 80
       }
     ]
    
  4. Enable Logging: Configure Ocelot's logging to capture detailed information about incoming requests and the routing decisions made by Ocelot. This can help identify specific URL mismatches or routing problems.

  5. Use URL Rewriting: If you need more control over URL manipulation, you can use IIS URL Rewrite to rewrite incoming requests to match your Ocelot's expectations.

Additional Value:

  • Understanding the Concept of Routing: Ocelot acts as a traffic director. It uses your configuration to determine how to forward requests to different backend services based on the incoming URL.
  • Benefits of Using an API Gateway: API Gateways like Ocelot simplify management, security, and performance aspects of your microservices architecture.

References:

Conclusion:

Deploying your .NET 6 Ocelot API Gateway to IIS requires careful consideration of URL handling and configurations. By following these steps and understanding the underlying concepts, you can avoid 404 errors and ensure your gateway operates seamlessly in your production environment.