Как справиться с жестко закодированными запросами веб-приложения при использовании блоков местоположения на основе пути?

Я пытаюсь создать обратный прокси-маршрут, используя nginx-прокси и докер для OpenTripPlanner (OTP) версии 1.5.0 и 2.2.0 на одном компьютере.

Если у меня есть простой блок местоположения, например:

location /otp2 {
        proxy_pass http://127.0.0.1:8081;
    }

Большинство вызовов, которые делает OTP, передаются вышестоящему серверу, однако веб-приложение OTP также имеет некоторые жестко закодированные вызовы для http://host/otp и http://host/images (нет http://host/otp2/otp и http://host/otp2/images). Поскольку они не соответствуют блоку местоположения nginx, они не могут быть разрешены.

Как я могу гарантировать, что эти вызовы также направляются на вышестоящий сервер?

Что я пробовал

Регулярное выражение + переписать

После долгих возни я остановился на:

location ~^/(otp2|otp|images) {          
        rewrite ^(/otp2)$ $1/ permanent;
        rewrite ^/(otp2)(.*) $2 break;
        rewrite ^/(otp)(.*) /$1$2 break;
        rewrite ^/(images)(.*) $1$2 break;                                                                                                                                                                           
        proxy_pass http://127.0.0.1:8081;
    }

Это работает, но это мешает мне запускать OTP версии 1.5.0 рядом с ним, так как этот бинарный файл также Запросы http://host/otp и http://host/images.

Кроме того, любое другое веб-приложение, которое я запускал бы на этом хосте, имело бы маршрут к /images вероятно, будет подобран этим блоком местоположения.

Субдомен

Я не могу вносить изменения в DNS, поэтому (я предполагаю) я могу делать только блоки местоположения на основе пути, а не поддомены, такие как otp2.host.com и otp1.host.com.

Отдельные блоки локаций

По предложению одного из ответивших я попробовал отдельные блоки местоположения:

location /otp2 {
    proxy_pass http://127.0.0.1:8081/;
}

location /otp2/otp {
    proxy_pass http://127.0.0.1:8081/otp/;
}

location /otp2/images {
    proxy_pass http://127.0.0.1:8081/images/;
}

Это частично работает, но оставляет несколько необработанных OTP-запросов, которые ломают приложение (хост формы sub1.sub2.company.country запутан на скриншоте ниже):

Как справиться с жестко закодированными запросами веб-приложения при использовании блоков местоположения на основе пути?

Саару Линдестокке

1 ответ
1

Давайте использовать отдельный блок местоположения для обработки определенных жестко заданных запросов от OTP 1.5.0 и 2.2.0, попробуйте эту конфигурацию:

server {
    listen 80;
    server_name your_host_name;

    # For OTP 1.5.0
    location /otp1 {
        proxy_pass http://127.0.0.1:8080;
    }

    location /otp1/otp {
        proxy_pass http://127.0.0.1:8080/otp;
    }

    location /otp1/images {
        proxy_pass http://127.0.0.1:8080/images;
    }

    # For OTP 2.2.0
    location /otp2 {
        proxy_pass http://127.0.0.1:8081;
    }

    location /otp2/otp {
        proxy_pass http://127.0.0.1:8081/otp;
    }

    location /otp2/images {
        proxy_pass http://127.0.0.1:8081/images;
    }

    # Additional web-apps with /images path
    location /other-web-app/images {
        proxy_pass http://127.0.0.1:8082/images;
    }

    # Handle remaining OTP v2 requests
    location /otp {
        proxy_pass http://127.0.0.1:8081/otp;
    }

    location /images {
        proxy_pass http://127.0.0.1:8081/images;
    }
}

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *