CODEWITHSUNDEEP
javascriptreactjsurlreact-routerrelative-path
amlwwalker
amlwwalker

Reputation: 3314

react router relative path to static files not loading correctly

I have a react app (simple frontend app) that in production is on a relative path (for instance suite.app.com/auth). Other apps are on different paths. So I need all requests for static files for this app to be routed via nginx to /auth. Basically this works fine from an nginx perspective but from a react perspective I need the paths to be relative:

In my package.json I have added "homepage": "./",

and in my index.html I have added <base href="/auth/">

So now when I load the files, I can see in the network tab of browser enter image description here

which is what I expect. Static files relative. However in my server logs when I load the app I can see this occuring:

enter image description here

I.e something is not passing the request to the correct path. (FWIW the reason they are coming back with 200's there, is because there is a different app on the root so its actually loading the other apps files, not this ones.

Any tips of what might be occuring here would be great.

EDIT: Posting the Nginx config for the two endpoints. The 

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;
    }
}

Upvotes: 0

Views: 2258

Answers (1)

miknik
miknik

Reputation: 5941

When you specify a proxy_pass directive then if you append anything to the end of the base URL Nginx will replace the portion of the original client request URL which matches your location block with whatever you have added to the proxy_pass URL.

So in your case you have location /auth and then proxy_pass http://authentication.internal.app/ with an all important trailing slash

So a client request to example.com/auth/static/style.css matches the location block /auth, Nginx drops /auth and replaces it with / and now your proxy is getting proxy.server//static/style.css

If you drop the slash to change your proxy_pass directive to proxy_pass http://authentication.internal.app the entire client request URL will be passed to the proxy, so the above request will be proxied to proxy.server/auth/static/style.css. For the opposite effect, leave the proxy_pass value as it is and change the location block to location /auth/ and Nginx will now replace /auth/ with / and the proxied request will become proxy.server/static/style.css

Purely for readability I would swap the order of your location directives in your config file so that the first entry is location /

It's a common misconception that Nginx evaluates location directives in the order they are listed and chooses the first match, but this is only true for locations defined by regular expressions.

All prefix matches are evaluated regardless of the order they are listed and Nginx selects the longest matching prefix location. The request is now evaluated against all location blocks containing regular expressions, this part does happen in the order they are listed, and if any of them match Nginx will immediately forget the longest prefix location and pass the request to the matching regex location. If none match then the best prefix match will handle the request.

You can prevent Nginx for searching for regex matches for requests matching a certain prefix location by adding the ^~ modifier before the location.

Obviously there are no regex locations in your current config so a lot of this is not relevant right now, but if you go down that route later it's not exactly intuitive so maybe it'll come in helpful at some point.

Upvotes: 3

Related Questions