Пустельга больше не разделяет путь и базу пути

Question

Я создал пример приложения фабричной службы в.NET Core и попытался зарегистрировать URL-адреса в Kestrel, но получил ошибку ниже. Пустельга больше не разделяет путь и основание пути. База путей, указанная в UseUrls(), больше не будет работать. Чтобы указать базу пути, используйте метод расширения IApplicationBuilder.UsePathBase().

ServerUrl будет: http://localhost:8597/School/LOCAL

Ниже приведен код в службах без сохранения состояния

public Task<string> OpenAsync(CancellationToken cancellationToken)
    {
        var endpoint = FabricRuntime.GetActivationContext().GetEndpoint(this._endpointName);
        string serverUrl = $"{endpoint.Protocol}://{FabricRuntime.GetNodeContext().IPAddressOrFQDN}:{endpoint.Port}";

        // serverUrl = http://localhost:8597
        serverUrl = serverUrl + "/School/LOCAL/";

        webHost = new WebHostBuilder()
                        .UseKestrel()
                        .UseContentRoot(Directory.GetCurrentDirectory())
                        .UseStartup<Startup>()
                        .UseUrls(serverUrl)
                        .Build();

        webHost.Start();

        return Task.FromResult(serverUrl);
    }

Поэтому я изменил свой код, как показано ниже, и попытался зарегистрировать свой URL с помощью IApplicationBuilder.UsePathBase(). Тем не менее, я заметил ниже поведение.

http://localhost:8597/School/LOCAL/api/getstudentnames - не работает http://localhost:8597/api/getstudentnames - работает

Изменения кода с использованием UsePathBase

CommunicationListener.CS

 public Task<string> OpenAsync(CancellationToken cancellationToken)
    {
        var endpoint = FabricRuntime.GetActivationContext().GetEndpoint(this._endpointName);
        string serverUrl = $"{endpoint.Protocol}://{FabricRuntime.GetNodeContext().IPAddressOrFQDN}:{endpoint.Port}";
        webHost = new WebHostBuilder()
                        .UseKestrel()
                        .UseContentRoot(Directory.GetCurrentDirectory())
                        .UseStartup<Startup>()
                        .UseUrls(serverUrl)
                        .Build();

        webHost.Start();

        return Task.FromResult(serverUrl);
    }

Startup.cs

 public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
    {
        const string PathBase = "/School/LOCAL/";
        app.UsePathBase(PathBase);
    }

Answer 1

Я думаю, что это работает, как ожидалось.

AFAIK, то UsePathBase() добавлена ​​функция удаления rootPath из фактического пути, полученного в запросе сценариев, когда клиент запрашивает что-либо через обратный прокси-сервер, который направляет запросы на основе VirtualPath и исходный URL-адрес должен быть переписан в службе, чтобы понять это.

Как пример:

• API принимает запросы на http://<anyip>/users/123
• API выставляется за настройкой прокси как виртуальный каталог, такой как http://domain/api
• Звонок клиента http://domain/api/users/123
• Прокси получит звонок как http://domain/api/users/123 и вперед, как есть API, http://domain/users/123
• API не распознает URL и возвращает 404,

В этом случае, если вы настраиваете с UserPathBase("api") это лишит api значение из URL для сопоставления с маршрутом, который у вас был раньше.

Пример - тот, о котором сообщают по этой проблеме, как ниже:

    public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
    {
        app.UsePathBase("/basepath");

        app.Map("/ping", map => map.Run(async 
            ctx => await ctx.Response.WriteAsync("pong")));

        app.UseMvc();
    }

Это будет работать для обоих URL ниже:

• /basepath/ping
• /ping

Поскольку basepath в первом будет удален и API всегда будет видеть второй вариант.

Это объясняет более подробно, и это показывает проблему, похожую на вашу.

Другая проблема, когда API возвращает внутренние URL-адреса, например, если нужно сгенерировать ссылку на пользователя, не зная, что он находится за прокси-сервером, он вернет http://<anyip>/users/123 где должен быть правильный URL http://<anyip>/api/users/123,

Таким образом, API должен выполнять работу, которую должен выполнять прокси-сервер, но некоторые прокси-серверы являются просто мостом и не обрабатывают эти случаи.