Rewrite rule gives 404 when fetching assets

Hello,

I have the current setup on Render:

  • a (empty) static website (apps) hosted under the custom domain apps.mydomain.com
  • a static app (let’s call it app1) reachable at https://app1.onrender.com

I am trying to set up a rewrite rule for the empty apps website, such that
apps.mydomain.com/app1 will show my app1. The goal would be to have different apps hosted independently on Render, and then access them through apps.mydomain.com/appN using rewrites.

However, when doing that, I get a blank page when visiting https://apps.mydomain.com/app1. When inspecting the network tab, I see that the correct content (the js and the css) is trying to be fetched from app1, but it returns a 404.
Weirdly, the title of the tab in the browser is the correct one (e.g., “App 1”), as well as the favicon.

When I change the rewrite to be a redirect, everything works as expected, but of course I have app1.onrender.com on the address bar.

This is how I have set up the rewrite rule in apps:

The “apps” app is literally just an “empty” index.html file, while app1 is a static app create using Vite.

Hi,

I’m not sure I understand the use-case of rewriting Static Sites to other Static Sites, I expect it would be cleaner to build one static file structure with folders per “App” and deploy it in one.

However, I’m going to assume the destination Static Site is also using rewrites? A rewrite to a rewrite is unlikely to work as expected. Maybe the destination HTML file can be referenced directly, rather then multi-level rewriting?

Alan

Thank you for your answer!

The idea was to start off by hosting a few simple (static) applications under apps.mydomain.com/<app-name> while keeping them hosted independently on Render, and in the future also maybe extend to dynamic services. I did not like the idea of having multiple apps in a single repo or using a subdomain app-name.mydomain.com for each app. That’s why I though of having sort of an “app router” static page.

I am more than happy to hear about a better solution if you have it!

Besides that, could you help me understand your point?

  • I don’t think the destination site is also using rewrites (at least, I did not set up any).
  • How could I reference the HTML directly? I have also tried to rewrite directly to app1.onrender.com/index.html, without luck.

Here is what I see in the network tab:

image

The index.html is actually fetched correctly and I can see that in the Elements tab. The problem lies in the assets (js and css) which are served under the assets folder.

Could this be an issue with the Vite/node config of the app?

It’s hard to assist when talking in generalities and fake domains.

If you’re not using rewrites on the destination, another issue could be that your destination site has references to its assets that are absolute to the root of that site. With the rewrite, that site is now under a path - /<app-name> - of another domain, so the JS and CSS references are likely incorrect.

For example:

  • app-name.domain.com runs index.html which calls /static/styles.css (app-name.domain.com/static/styles.css)

  • When served through the rewrite for /app-name the URLapp-router.domain.com/app-name will serve the HTML as-is, so the reference to /static/styles.css is now looking for app-router.domain.com/static/styles.css which won’t exist.

The destination site would likely need to use relative references to its assets.

Alan

Dear Alan,

thanks for the help, I will gladly share the details here!

The app is at https://hanoi-tower.onrender.com and I am trying to reach it from https://apps.mantovani.dev/hanoi-tower (apps.mantovani.dev hosts the “app router” which is also at https://app-router.onrender.com).

I have checked relative paths and assets for Vite and came to this Github discussion Relative Path in Generated index.html · vitejs/vite · Discussion #5081 · GitHub and to the Vite documentation. Apparently I needed to set base: './' in the Vite config file.

I can see now in the index.html that the two assets are referenced with the relative path (there was no ‘.’ before):

However, they are still not accessible.

Your rewrite would likely need to pass that additional asset path with wildcard declarations: https://docs.render.com/redirects-rewrites#wildcards

Alan

Hi Alan,

thanks again for your patience.

I have set up the wildcard as follows:

(for the second I have https://hanoi-tower.onrender.com/assets/*) as destination.

Now, I have tried again apps.mantovani.dev/hanoi-tower gives me again 404, but appending a single / at the end, that is, apps.mantovani.dev/hanoi-tower/ gave me a CORS error for the assets.

I added a CORS header to the hanoi-tower app in Render, and now it works: I can access the app at apps.mantovani.dev/hanoi-tower/. But I have to put the slash at the end. Visiting the URL without the ending slash will give me again a 404 on the assets.

Do you have an idea what might be the issue now?

Thanks a lot for the help so far.

I’d expect 2 rewrites to be required. They’re also ordered:

  • /hanoi-towerhttps://hanoi-tower.onrender.com to handle https://apps.mantovani.dev/hanoi-tower
  • /hanoi-tower/*https://hanoi-tower.onrender.com/* to handle everything else.

Alan

Hi Alan,

I have tried your suggested rewrites and several combinations of those two, including/excluding assets, trailing slashes and so on, but I am able to access the URL from a browser only if I put the slash at the end:

apps.mantovani.dev/hanoi-tower/

If I try to curl the assets from the command line with, e.g., curl -v https://apps.mantovani.dev/hanoi-tower/assets/index-IC2oEpCc.js, I am able to fetch the content.

I have also tried to set up a redirect from /hanoi-tower to /hanoi-tower/, but this ends up in a TOO_MANY_REDIRECT error. I thought this topic could be related: Redirect rule is redirecting too much.

Am I missing something obvious?

Mattia

I’m not sure. I tried out my previous suggestion in my own account with similar paths and it worked.

Just 2 rewrites - the root, and everything else. Your last screenshots show you’re specifically targeting /assets, which feels too specific.

Or you may be running up against an unintended use-case, as I was alluding to in my first reply.

Alan

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.