International proxy redirects issue

Support
1

I’ve done quite a bit of reading on the subject:

And I can get things working individually (the country redirect and the proxy) but having trouble getting everything to work together with my environments.

The scenario is, we’ll have a main site that contains a homepage and subpages, /a for example, which will cover users from countries that we aren’t managing sub-sites for. We then will have a series of sub sites for different countries and/or locations that we’ll proxy to a sub-folder (ie /en-au/). These sub sites will also contain a homepage and potentially the same subpage urls.

/   /en-au/ 302 Country=au,nz
/en-au/*  https://sub-site-au.netlify.app/:splat  200

This doesn’t automatically redirect the user in Australia because the main site managing the redirects contains a homepage, therefore matches and does not get to the redirect rule to force the user to /en-au/, however, does work if you manually enter the url. So I force the 302:

/   /en-au/ 302! Country=au,nz
/en-au/*  https://sub-site-au.netlify.app/:splat  200

This works to force users located in either Australia or New Zealand to the site URL /en-au/ for the homepage - great! But what if the user comes in at subpage /a? It skips over these rules and stays on the main site. So you’d be forgiven in thinking that adding a splat to the country redirect would then work:

/*   /en-au/:splat 302! Country=au,nz
/en-au/*  https://sub-site-au.netlify.app/:splat  200

However, this doesn’t work. Even though the URL in the browser is maindomain.com/en-au/a which is right, its returning a 404, where I would have expected this setup to proxy into that view the content on the URL of https://sub-site-au.netlify.app/a. What it believe its doing is its hitting that prior 302 redirect and attempting /en-au/en-au/a or even resulting in an infinite loop (technically) since its picking up the wildcard.

So - the question is, how do you force all paths for a user in a particular country to view a proxy without defining all the paths individually?

3

Hey @AshMatter,

I think this would be a good use case for Edge Functions. You can use context.geo:

and determine what kind of redirect to send. In that, you can make various combinations and events on when to actually redirect. The way this would probably work is:

Add an edge function for all paths → if the request path is your sub-folder, simply send it to the next function → this would be handled by your redirect for that particular sub-folder

If the request path is your home page, use the context.geo object to determine which path to redirect to.

In this situation, now you only need redirects for all the country paths like:

/en-au/*  https://sub-site-au.netlify.app/:splat  200
/en-us/*  https://sub-site-au.netlify.app/:splat  200
/en-gb/*  https://sub-site-au.netlify.app/:splat  200

Inside your Edge Function, on the home page, you’d be checking the Geo object and send a 302 to the sub-path. On the sub-path, you would be skipping the processing using next.

I have just worded this in my head without any testing, but based on my understanding, this should work fine. Let us know how it goes.

Also, I noticed you’ve already posted this in the helpdesk - but the suggestion there has not helped you, so instead of continuing that conversation, I decided to post this in forums so it might help more people with similar use cases.

4

Hey @hrishikesh,

Thanks. This actually helps in more ways than one as we ended up changing things slightly to instead of automatically redirect the user, to instead provided them with a notification there is an optimised local version for their region, to enable the ability to view other regions, would they wish to.

One thing I have noticed in this process is that whilst the proxy redirects work to display the sub-site, its a broken view of it because the sub sites JS files do not rewrite, so the page tries to load the sub site asset via the main domain.

The documentation for proxies do state:

  • Rewrites can cause pages that use assets specified through relative paths to load incorrectly. To make sure your site’s proxied content is displayed as expected, use absolute paths for your assets or a <base> tag.

However, the file in question is the JS generated file, so I don’t set the URL for this. Am I missing a configuration of some sort?

6

Could you provide an example of how exactly you’re generating the file? In most cases, you should be able to set the URL of the site being proxied to as the <base> tag - so as far as I can think, you should be already knowing it and should be able to hardcode it.

Is there something I’m not understanding correctly?

7

The file mentioned is the standard JS bundle file from Gatsby so I don’t have control of the reference to that file, at least not within the template itself.

I can’t hardcode any URLs either as the same repo and theme is used for all subsites, with each pulling different content based on the environment variables provided to that instance.

The example being:
https://site.netlify.app/app-28f29d2ef7e0cd5dc839.js where it needs to either be:
https://subsite-au.netlify.app/app-28f29d2ef7e0cd5dc839.js or https://site.netlify.app/en-au/app-28f29d2ef7e0cd5dc839.js to actually find the file

8

@hrishikesh just to close the <base> tag conversation, I have attempted to add this to the project, and whilst I was successful and it displays in the head of the page correctly when viewing the subsites, it has zero effect on the script paths.
Furthermore, there are many downsides to using the tag, so I’m finding out, and is generally discouraged to use - especially for Gatsby:

I will instead look further into this linkPrefix as the replacement

9

So pathPrefix works perfectly, except for when wanting to link to other subsites. ie if on https://site.netlify.app/en-au/ and you want the user to be able to go to https://site.netlify.app/en-gb/, the link is https://site.netlify.app/en-au/en-gb/. Apart from this, the pathPrefix solution does fix the assets loading correctly.

I think we have a solution sorted now from Netlify’s POV - just need to fix the configuration of the prefix which is now a gatsby problem.

Thanks