Прокси-серверы функций Azure настраивают перенаправления на URL-адрес backendUri.

У меня есть приложение-функция Azure, где я хочу использовать прокси-сервер для отображения статической страницы пользователям (которая размещена в другом домене) после доступа к ссылке на приложение-функция, как в примере ниже https://myfunctionapp1.azurewebsites.net/

{
    "$schema": "http://json.schemastore.org/proxies",
    "proxies": {
        "default": {
            "matchCondition": {
                "methods": [
                    "GET"
                ],
                "route": "/"
            },
            "backendUri": "https://my-site.azurewebsites.net/default.htm"

        }
    }
}

Приведенная выше конфигурация, которую я сделал год назад, показывает статическую страницу по тому же URL-адресу, но теперь, когда я перехожу по ссылке https://myfunctionapp1.azurewebsites.net/ перенаправляет на https://my-site.azurewebsites.net/default.htm

Есть ли какие-либо новые изменения в документации по прокси-серверу функций Azure? Если да, пожалуйста, перейдите по ссылке здесь Спасибо и с уважением


azure-function-app azure-function-app-proxy
person Kumari Dimple    schedule 13.01.2020    source источник
comment
Вы когда-нибудь выясняли, как вернуть старое поведение? Я столкнулся с той же проблемой, которая является проблематичной, поскольку мы хотим, чтобы пользователи в браузерах видели исходный URL-адрес, а не базовый внутренний URL-адрес, который мы хотим изменить, и по-прежнему влиять на потенциальные закладки, созданные пользователями в браузерах.   -  person michn    schedule 30.11.2020

Ответы (1)


arrow_upward
0
arrow_downward

Я столкнулся с аналогичной проблемой, когда прокси-сервер функции перенаправляет браузер на внутренний URI вместо отображения результатов из внутреннего URI на URL-адресе прокси.

Оказывается, если внутренний URI отвечает перенаправлением 301 или 302, прокси-сервер вернет это перенаправление в браузер пользователя, и поэтому браузер выполнит перенаправление вместо того, чтобы просто показать содержимое внутреннего URI.

В моем случае это перенаправление 301 было вызвано тем, что внутренний URI был https://[domain].com, который выполнял перенаправление на https://www.[domain].com. Изменение моего внутреннего URI на https://www.[domain].com устранило проблему, и теперь он работает, как предполагалось.

person michn    schedule 17.12.2020