Относительно правильно реагировать роутер на статические файлы, которые не загружаются - PullRequest
Новая
       20

Относительно правильно реагировать роутер на статические файлы, которые не загружаются

0 голосов
/ 05 июля 2018

У меня есть приложение реагирования (простое приложение внешнего интерфейса), которое в производственном процессе находится на относительном пути (например, suite.app.com/auth). Другие приложения находятся на разных путях. Поэтому мне нужно, чтобы все запросы статических файлов для этого приложения направлялись через nginx в / auth. В принципе, это нормально работает с точки зрения nginx, но с точки зрения реакции мне нужны относительные пути:

В моем package.json я добавил "homepage": "./",

и в моем index.html я добавил <base href="/auth/">

Так что теперь, когда я загружаю файлы, я вижу на вкладке сети браузера enter image description here

что я и ожидаю. Статические файлы относительные. Однако в журналах моего сервера при загрузке приложения я вижу следующее:

enter image description here

Т.е. что-то не передает запрос на правильный путь. (FWIW причина, по которой они возвращаются с 200-ыми, заключается в том, что в корневом каталоге есть другое приложение, поэтому оно фактически загружает файлы других приложений, а не эти.

Любые подсказки о том, что может происходить здесь, были бы великолепны.

РЕДАКТИРОВАТЬ: Публикация конфигурации Nginx для двух конечных точек. 

server {
    listen 80;
    server_name app.site.com;
    add_header 'Referrer-Policy' 'origin';
    location /auth {
        proxy_pass http://authentication.internal.app/;
        proxy_set_header Host authentication.internal.app;
        proxy_http_version 1.1;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header X-Real-IP $proxy_protocol_addr;
        proxy_set_header X-Forwarded-For $proxy_protocol_addr;
        proxy_set_header X-Forwarded-Proto https;
        proxy_redirect off;
    }
    location / {
        proxy_pass http://dashboard.internal.app/;
        proxy_set_header Host dashboard.internal.app;
        proxy_http_version 1.1;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header X-Real-IP $proxy_protocol_addr;
        proxy_set_header X-Forwarded-For $proxy_protocol_addr;
        proxy_set_header X-Forwarded-Proto https;
        proxy_redirect off;
    }
}

1 Ответ

0 голосов
/ 06 июля 2018

Когда вы указываете директиву proxy_pass, тогда, если вы добавляете что-либо в конец базового URL, Nginx заменит часть исходного URL-адреса запроса клиента, которая соответствует вашему блоку местоположения, тем, что вы добавили к URL-адресу proxy_pass .

Так что в вашем случае у вас есть location /auth, а затем proxy_pass http://authentication.internal.app/ со всеми важными конечными слешами

Таким образом, клиентский запрос к example.com/auth/static/style.css соответствует блоку местоположения /auth, Nginx сбрасывает /auth и заменяет его на /, и теперь ваш прокси получает proxy.server//static/style.css

Если вы выберете косую черту, чтобы изменить директиву proxy_pass на proxy_pass http://authentication.internal.app, весь URL-адрес запроса клиента будет передан прокси-серверу, поэтому вышеупомянутый запрос будет перенаправлен на proxy.server/auth/static/style.css. Для обратного эффекта оставьте значение proxy_pass как есть и измените блок местоположения на location /auth/, и теперь Nginx заменит /auth/ на /, а запрос на прокси станет proxy.server/static/style.css

Чисто для удобства чтения, я бы поменял местами порядок директив вашего местоположения в вашем конфигурационном файле, чтобы первая запись была location /

Распространено заблуждение, что Nginx оценивает директивы местоположения в порядке их перечисления и выбирает первое совпадение, но это верно только для местоположений, определенных регулярными выражениями.

Все совпадения префиксов оцениваются независимо от того, в каком порядке они перечислены, и Nginx выбирает самое длинное совпадающее местоположение префикса. Теперь запрос оценивается по всем блокам местоположения, содержащим регулярные выражения, эта часть выполняется в том порядке, в котором они перечислены, и, если какой-либо из них совпадает с Nginx, он немедленно забудет самое длинное местоположение префикса и передаст запрос в соответствующее местоположение регулярного выражения. Если ни один из них не совпадает, то наилучшее совпадение префикса обработает запрос.

Вы можете запретить Nginx выполнять поиск совпадений регулярных выражений для запросов, соответствующих определенному расположению префикса, добавив модификатор ^~ перед местоположением.

Очевидно, что в вашей текущей конфигурации нет мест для регулярных выражений, поэтому многое из этого сейчас неактуально, но если вы пойдете по этому маршруту позже, это не совсем интуитивно, так что, возможно, в какой-то момент это пригодится.

...