В ядре ASP.NET существует такая концепция, известная как base base . Основная идея довольно проста для понимания: база пути считается фиксированным префиксом для пути всех входящих запросов к вашему веб-приложению. По умолчанию основанием пути считается пустая строка.
Это означает, что по умолчанию при поступлении запроса в ваше приложение вся часть пути URL-адреса запроса будет сопоставлена с *Свойство 1006 * объекта HttpRequest и свойство PathBase будут установлены в string.empty.
В качестве примера рассмотрим основное приложение asp.net, работающее на вашем локальном компьютере и прослушивающее порт 3000. Предположим, что вы запускаете приложение с помощью веб-сервера raw kestrel (поэтому обратный прокси-сервер не задействован, запросы поступают непосредственно в kestrel).
Когда вы запрашиваете URL http://localhost:3000/foo/bar, объект HttpRequest будет иметь следующие свойства:
HttpRequest.Path будет установлен на /foo/bar
Такая же ситуация возникнет, если вы решите разместить свое приложение в Azure с помощью службы приложений Windows.
В этом сценарии размещения по умолчанию базовое веб-приложение ASP.NET выполняется внутри того же процесса, что и рабочий процесс IIS. Это в основном означает, что задействован только один процесс;опять нет обратного прокси и веб-сервер kestrel вообще не используется: запрос обрабатывается IIS напрямую (вы можете найти некоторые детали здесь , если вы заинтересованы).
Inв этом случае общедоступный URL-адрес вашего приложения будет выглядеть примерно так: https://my-application.azurewebsites.net. При переходе по URL-адресу https://my-application.azurewebsites.net/foo/bar ситуация для входящего http-запроса будет следующей:
HttpRequest.Path будет установлено на /foo/barHttpRequest.PathBaseбудет установлено значение string.empty
Опять, как и прежде, основанием пути является пустая строка.
Существуют различные сценарии хостинга, в которых вы можете решить выставить свое приложение, используя виртуальный каталог.
Например, вы можете принять решение разместить основное веб-приложение asp.net в своем собственном центре данных, используя виртуальную машину Windows с установленным IIS. В этом случае у вас может быть существующий веб-сайт в IIS, и вы хотите создать виртуальное приложение с соответствующим псевдонимом для этого веб-сайта. Снова в этом сценарии, как объяснено выше для службы приложений Azure Windows, обратный прокси-сервер не задействован, и веб-сервер kestrel вообще не используется: запрос обрабатывается непосредственно рабочим процессом IIS ( в модели размещения процессов). ).
Предположим, что общедоступным URL вашего веб-сайта является https://sample-application.contoso.net и что вы выбрали sample-alias в качестве псевдонима для виртуального приложения. Это означает, что все запросы к вашему главному веб-приложению asp.net будут иметь часть пути, начинающуюся с sample-alias. Например, если вам требуется домашняя страница приложения, перейдите на https://sample-application.contoso.net/sample-alias.
В этом случае, когда вы запрашиваете URL https://sample-application.contoso.net/sample-alias/foo/bar, объект HttpRequest в вашем приложении будет выполняться следующим образом:
HttpRequest.Path будет установлен в/foo/barHttpRequest.PathBase будет установлен на sample-alias
Из-за способа создания веб-хоста по умолчанию для основного приложения ASP.NET этот сценарий включает IISВиртуальные приложения работают «из коробки», и конвейер промежуточного программного обеспечения знает общий префикс для всех входящих HTTP-запросов, и он может установить для базы пути значение sample-alias, а для свойства пути - оставшуюся часть пути входящего запроса (/foo/bar в моем примере выше).
Как правило, вы можете считать, что основное веб-приложение ASP.NET прекрасно работает без каких-либо дополнительных настроек, если вы хотите разместить его с помощью IIS. Это верно и для базового свойства пути (проверьте здесь , чтобы убедиться, что базовый путь запроса автоматически устанавливается внутри вашего приложения в stratup).
В качестве последнего примера рассмотрите возможность размещения вашего приложения на компьютере с Linux, используя nginx в качестве обратного прокси-сервера. В этом случае ваше приложение будет выполнено на веб-сервере kestrel, но оно не будет открыто для публичного Интернета. Общедоступным Интернетом является веб-сервер nginx, который направляет входящие HTTP-запросы на веб-сервер kestrel (где выполняется ваше приложение). Вы можете настроить nginx так, чтобы все запросы, начинающиеся с префикса /awesome-application, были направлены в ваше основное веб-приложение asp.net.
Например, предположим, что nginx открыт для общедоступного Интернета по URL-адресу https://ingress.contoso.net: в этом случае, если вы хотите запросить домашнюю страницу своего приложения, вам нужно перейти к https://ingress.contoso.net/awesome-application/.
В этом случае вы не можете получить awesome-application базу пути запроса бесплатно (по умолчанию kestrel не знает об этом и считает базу пути запроса string.empty).
Чтобы kestrel знал о базе путей запросов, вам необходимо использовать UsePathBaseMiddleware в качестве первого элемента в вашем конвейере промежуточного программного обеспечения.
Если вам нужны дополнительные сведения для этого случая, следуйте этой документации и см. Также этот вопрос о переполнении стека .