301 redirect behavior for sub paths and multiple destinations

[kkbruce]

We are preparing to transfer NGINX services to YARP. We found some problems during the test and want to ask for advice.

YARP version:

  <ItemGroup>
    <PackageReference Include="Yarp.ReverseProxy" Version="1.1.0" />
  </ItemGroup>

Program.cs

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddReverseProxy()
    .LoadFromConfig(builder.Configuration.GetSection("ReverseProxy"));
var app = builder.Build();
app.MapReverseProxy();
app.Run();

appsettings.Development.json

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning",
      "Yarp": "Debug"
    }
  },
  "ReverseProxy": {
    "Routes": {
      "teamdoc_7000": {
        "ClusterId": "teamdoc",
        "Match": {
          "Path": "/teamdoc/{*remainder}"
        }
      },
      "teamportal_7002": {
        "ClusterId": "teamportal",
        "Match": {
          "Path": "/{**remainder}"
        }
      }
    },
    "Clusters": {
      "teamdoc": {
        "Destinations": {
          "destination1": {
            "Address": "http://aaa:7000/"
          },
          "destination2": {
            "Address": "http://bbb:7000/"
          },
          "destination3": {
            "Address": "http://ccc:7000/"
          }
        }
      },
      "teamportal": {
        "Destinations": {
          "destination1": {
            "Address": "http://aaa:7002/"
          },
          "destination2": {
            "Address": "http://bbb:7002/"
          },
          "destination3": {
            "Address": "http://ccc:7002/"
          }
        }
      }
    }
  }
}

We are a container environment. CD will deploy each service to AAA, BBB, and CCC Docker hosts. For example, the Doc service on port 7000 and the Portal service on port 7002.

Original architecture:

NGINX <--> Portal (a,b,c Host, port 7002)   <--> Doc1 (a,b,c Host, port 7000)
                                            <--> Doc2 (a,b,c Host, port 7001)
                                            <--> ...

Alternative architecture：

YARP <--> Portal (a,b,c Host, port 7002)    <--> Doc1 (a,b,c Host, port 7000)
                                            <--> Doc2 (a,b,c Host, port 7002)
                                            <--> ...

Running log

Yarp.ReverseProxy.Management.ProxyConfigManager: Debug: Destination 'destination1' has been added.
Yarp.ReverseProxy.Management.ProxyConfigManager: Debug: Destination 'destination2' has been added.
Yarp.ReverseProxy.Management.ProxyConfigManager: Debug: Destination 'destination3' has been added.
Yarp.ReverseProxy.Forwarder.ForwarderHttpClientFactory: Debug: New client created for cluster 'teamdoc'.
Yarp.ReverseProxy.Management.ProxyConfigManager: Debug: Cluster 'teamdoc' has been added.
Yarp.ReverseProxy.Management.ProxyConfigManager: Debug: Destination 'destination1' has been added.
Yarp.ReverseProxy.Management.ProxyConfigManager: Debug: Destination 'destination2' has been added.
Yarp.ReverseProxy.Management.ProxyConfigManager: Debug: Destination 'destination3' has been added.
Yarp.ReverseProxy.Forwarder.ForwarderHttpClientFactory: Debug: New client created for cluster 'teamportal'.
Yarp.ReverseProxy.Management.ProxyConfigManager: Debug: Cluster 'teamportal' has been added.
Yarp.ReverseProxy.Management.ProxyConfigManager: Debug: Route 'teamdoc_7000' has been added.
Yarp.ReverseProxy.Management.ProxyConfigManager: Debug: Route 'teamportal_7002' has been added.
Microsoft.Hosting.Lifetime: Information: Now listening on: https://localhost:7273
Microsoft.Hosting.Lifetime: Information: Now listening on: http://localhost:5111
Microsoft.Hosting.Lifetime: Information: Application started. Press Ctrl+C to shut down.
Microsoft.Hosting.Lifetime: Information: Hosting environment: Development
Microsoft.Hosting.Lifetime: Information: Content root path: Z:\myproxy\
Yarp.ReverseProxy.Forwarder.HttpForwarder: Information: Proxying to http://ccc:7002/ HTTP/2 RequestVersionOrLower no-streaming
Yarp.ReverseProxy.Forwarder.HttpForwarder: Information: Received HTTP/1.1 response 200.
Yarp.ReverseProxy.Forwarder.HttpForwarder: Information: Proxying to http://aaa:7002/ HTTP/2 RequestVersionOrLower no-streaming
Yarp.ReverseProxy.Forwarder.HttpForwarder: Information: Received HTTP/1.1 response 200.
Yarp.ReverseProxy.Forwarder.HttpForwarder: Information: Proxying to http://aaa:7002/ HTTP/2 RequestVersionOrLower no-streaming
Yarp.ReverseProxy.Forwarder.HttpForwarder: Information: Received HTTP/1.1 response 200.
Yarp.ReverseProxy.Forwarder.HttpForwarder: Information: Proxying to http://aaa:7002/ HTTP/2 RequestVersionOrLower no-streaming
Yarp.ReverseProxy.Forwarder.HttpForwarder: Information: Received HTTP/1.1 response 200.
Yarp.ReverseProxy.Forwarder.HttpForwarder: Information: Proxying to http://bbb:7002/ HTTP/2 RequestVersionOrLower no-streaming
Yarp.ReverseProxy.Forwarder.HttpForwarder: Information: Received HTTP/1.1 response 200.
Yarp.ReverseProxy.Forwarder.HttpForwarder: Information: Proxying to http://bbb:7000/teamdoc HTTP/2 RequestVersionOrLower no-streaming
Yarp.ReverseProxy.Forwarder.HttpForwarder: Information: Received HTTP/1.1 response 301.
Yarp.ReverseProxy.Forwarder.HttpForwarder: Information: Proxying to http://aaa:7000/teamdoc HTTP/2 RequestVersionOrLower no-streaming
Yarp.ReverseProxy.Forwarder.HttpForwarder: Information: Received HTTP/1.1 response 301.

In the beginning, 「"Path": "/{**remainder}"」 can directly access one of the host Portal services of AAA, BBB, and CCC as expected. However, when accessing the host of route rule 「"Path": "/teamdoc/{*remainder}"」 (the last two records in the log), YARP will be changed to 301 redirect, which will change the URL and lose the role of proxy.

I have tried many settings. In addition to the access of the root path, as long as the access of the sub-path has multiple destinations, the request will be made in the behavior of 301 redirect, which bothers me.

[Tratcher]

What's the Location header included in the 301s? We need to understand why the destination is redirecting before we can suggest how to fix it.

[Tratcher]

Ah, I see. "/teamdoc" and "/teamdoc/" are considered different resources but some applications decide to unify them by redirecting to add the trailing slash. If you accessed "/teamdoc/" instead of "/teamdoc" you probably wouldn't see a redirect.

The problem is that the destination server only knows its own hostname and uses that when generating the redirect. One way to mitigate this is by producing your own redirect on the front end from "/teamdoc" to "/teamdoc/", either without a hostname, or with your public hostname. That should prevent redirects from happening when you forward the request to the destination. See https://docs.microsoft.com/en-us/aspnet/core/fundamentals/url-rewriting

[kkbruce]

The key point is the difference between /teamdoc and /teamdoc/; let me take a moment to understand cause and effect.

[kkbruce]

@Tratcher

I can simulate the 301 problems with IIS on my computer.

When receiving a /teamdoc request in IIS, IIS will respond with a 301 /teamdoc/ to the browser, which is why YARP will 301 to a specific host. NGINX will not send 301 back to the client and continue to read the website along 301, but YARP will send it back to the client, and the client will follow the instructions of 301 to go to a specific host.

I know it's not a YARP problem, but users may make the same typos as I do. Hopefully, YARP may provide options to deal with issues like 301, whether to respond to the client or continue reading endpoints (whether website or API) along 301 like NGINX.

Thanks for your help.

[Tratcher]

That 301 is intended for the client, I don't know why NGinx seems to be handling it.

IIS has this behavior because of the rules on how relative resources are resolved in a web page. When the client receives some HTML it may contain relative resource links for content like images. The rules for resolving those relative links look like this:
/page/ + image.jpg = /page/image.jpg
/page + image.jpg =/image.jpg
(See RFC 3986)

So if the client doesn't see the 301 from /teamdoc to /teamdoc/ then it won't be able to correctly resolve resources.

In short, the 301 is supposed to be there with or without a proxy, it's a feature, not a bug.

[kkbruce]

I agree with what you said.