Nginx proxy_pass gaat verkeerd met subdirectory

[FiXeR.nl]

Ik probeer een door middel van een reverse proxy een webapp benaderbaar te maken met nginx. Dit (python)programma draait in een dockercontainer en is benaderbaar op poort 881. Als ik via ssh een tunnel aanmaak op poort 881 kan ik het programma prima benaderen, tot zo ver werkt dat allemaal goed.

Ik wil dat programma beschikbaar maken op ons subdomein "tools.afdeling.bedrijf.com/app2/" (app1 is al in gebruik en werkt prima)

Hiervoor heb ik in Nginx bij de vhost config dus een nieuwe location aangemaakt:

code:

        location /app2 {
            proxy_pass http://127.0.0.1:881/;
        }

Nu kan ik de app benaderen via "tools.afdeling.bedrijf.com/app2/" maar gaat er met de code iets fout, namelijk de javascript en images verwijzen naar "tools.afdeling.bedrijf.com/images" in plaats van "tools.afdeling.bedrijf.com/app2/images"

Ik heb al verschillende dingen geprobeerd met rewrites, slashes achter de map naam en proxy_setheaders geprobeerd maar ik begin haast te denken dat nginx dit gewoon niet kan.

Wellicht heeft iemand de gouden tip, na ruim 2 uur googlen en tientallen verschillende configs werkt het nog steeds niet.

[Wolfboy]

Dit kan wel met Nginx, via de nginx_substitutions_filter: https://www.nginx.com/resources/wiki/modules/substitutions/

Maar ik zou toch aanraden de configuratie van het Python programma even aan te passen, mits die goed gebouwd is kan je de url zo veranderen. Al is het alleen al om de plaatjes een keer naar een subdomein te verplaatsen zodat het wat sneller kan laden.

[Blokker_1999]

Dit klinkt stom maar pas je config eens aan naar:

code:

location /app2/ {
            proxy_pass http://127.0.0.1:881;
        }

If proxy_pass is specified without a URI, the request URI is passed to the server in the same form as sent by a client when the original request is processed, or the full normalized request URI is passed when processing the changed URI:

location /some/path/ {
proxy_pass http://127.0.0.1;
}

Before version 1.1.12, if proxy_pass is specified without a URI, the original request URI might be passed instead of the changed URI in some cases.

De laatste / in de proxy_pass lijn zorgt er namelijk voor dat je een eigen $uri opgeeft ipv deze over te nemen van de originele aanvraag.

[ Voor 10% gewijzigd door Blokker_1999 op 06-01-2016 10:15 ]

[FiXeR.nl]

Wolfboy schreef op woensdag 06 januari 2016 @ 09:44:
Dit kan wel met Nginx, via de nginx_substitutions_filter: https://www.nginx.com/resources/wiki/modules/substitutions/

Maar ik zou toch aanraden de configuratie van het Python programma even aan te passen, mits die goed gebouwd is kan je de url zo veranderen. Al is het alleen al om de plaatjes een keer naar een subdomein te verplaatsen zodat het wat sneller kan laden.

Dit ga ik straks eens proberen, deze had ik nog niet gevonden. Helaas kan ik de app niet aanpassen. Op een of andere manier pakt hij dat niet lekker omdat het een docker is.

Blokker_1999 schreef op woensdag 06 januari 2016 @ 10:13:
Dit klinkt stom maar pas je config eens aan naar:

code:

location /app2/ {
            proxy_pass http://127.0.0.1:881;
        }

[...]

Dat had ik al geprobeerd, maar werkt helaas niet.

[Blokker_1999]

Ik moet u toch meedelen dat het hier perfect werkt. Heb je de trailing slach achter de proxy_pass weg gehaald of heb je enkel de toegevoegde slash bij location gezien?

Toegevoegd op de ene server:

code:

    location  /test/ {
        proxy_pass http://192.168.9.104;
    }

in de access log van de andere server (192.168.9.4) wanneer ik http://192.168.10.10/test/index.html vraag:

code:

192.168.10.10 - - [06/Jan/2016:11:18:43 +0000] "GET //test/index.html HTTP/1.0" 404 168 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:43.0) Gecko/20100101 Firefox/43.0"

Het is uiteraard wel belangrijk dat de server naarwaar je een proxy doet ook zelf de juiste subdir teruggeeft. Als die zelf ineens de subdir eruit gaat slopen in zijn antwoord dan zal je dat ten allen tijde moeilijk terug kunnen krijgen. Een proxy is dan ook een doorgeeflijk en geen rewrite systeem.

Niet vergeten van na het aanpassen van de config altijd best de server herstarten ipv reloaden.

[ Voor 18% gewijzigd door Blokker_1999 op 06-01-2016 12:26 ]

[deadinspace]

FiXeR.nl schreef op woensdag 06 januari 2016 @ 09:24:
Dit (python)programma draait in een dockercontainer en is benaderbaar op poort 881.

Betekent dat dat die python app als root draait in die docker container? Dat is niet per se een goed idee

Nu kan ik de app benaderen via "tools.afdeling.bedrijf.com/app2/" maar gaat er met de code iets fout, namelijk de javascript en images verwijzen naar "tools.afdeling.bedrijf.com/images" in plaats van "tools.afdeling.bedrijf.com/app2/images"

Ja, als die webapp absolute paden gebruikt (wat heel gebruikelijk is) voor dat soort dingen dan werkt dat niet;

Een makkelijke oplossing is om een subdomein te gebruiken voor de reverse proxy, zodat die app ook geproxied gewoon in de root van dat domein draait. "app2.tools.afdeling.bedrijf.com" bijvoorbeeld.

Een andere mogelijkheid is om te zorgen dat de applicatie (in docker) zelf ook onder /app2/ werkt. Dus dat je de app rechtstreeks op de docker container ook benadert met docker:881/app2/ . Dan verwijst de app uit zichzelf naar /app2/images/blabla waardoor dit samen werkt met de proxy (mits juist ingesteld, zie Blokker_1999's posts).

Wolfboy schreef op woensdag 06 januari 2016 @ 09:44:
Dit kan wel met Nginx, via de nginx_substitutions_filter: https://www.nginx.com/resources/wiki/modules/substitutions/

Dat kan echt alleen maar tot hoofdpijn leiden.

Stel, je subst /images/ naar /app2/images/. Als iemand dan een linkje naar google.com/images/bla.jpg opneemt in een comment in die app, dan wordt die link verklooid. Als de app geupdate wordt om ook /images2/ of /scripts/ of /styles/ of wat dan ook te gebruiken, dan werkt dat niet (en voordat je er dan weer achter bent waarom...). Als je / gaat substen dan ontploft dat zodra een slash in een niet-URL context gebruikt wordt (deling in JS bv). Etc, etc.

Serieus, doe het niet.

Maar ik zou toch aanraden de configuratie van het Python programma even aan te passen, mits die goed gebouwd is kan je de url zo veranderen.

Dat is ook een mogelijkheid. Je verliest dan wel de mogelijkheid de applicatie rechtstreeks te gebruiken (op blabla:881). Al zou je dat kunnen oplossen met een extra reverse proxy in de docker container.

Blokker_1999 schreef op woensdag 06 januari 2016 @ 12:24:
Ik moet u toch meedelen dat het hier perfect werkt.

Alleen als de app relatieve paden gebruikt, of ook geroot is in /app2/. Beiden zijn volgensmij niet het geval bij de TS

[FiXeR.nl]

deadinspace schreef op woensdag 06 januari 2016 @ 12:51:
[...]

Betekent dat dat die python app als root draait in die docker container? Dat is niet per se een goed idee

[...]


Een makkelijke oplossing is om een subdomein te gebruiken voor de reverse proxy, zodat die app ook geproxied gewoon in de root van dat domein draait. "app2.tools.afdeling.bedrijf.com" bijvoorbeeld.

Uiteindelijk heb ik dit gedaan als oplossing, alle andere oplossingen werkte allemaal niet. En de rewrite-module heb ik (op jouw aanraden) niet getest.