-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
make adapter-node
base path configurable via environment variable
#7242
Comments
Adding another comment from #3726 which is relevant: Oh, I really need this to be fixed. I cannot use the workaround mentioned earlier because my case is one level more complex as I need to use the generated middleware handler in another express server (directus). I cannot control exactly when to
|
if (options.paths.base && !state.prerendering?.fallback) { | |
if (!decoded.startsWith(options.paths.base)) { | |
return new Response('Not found', { status: 404 }); | |
} | |
decoded = decoded.slice(options.paths.base.length) || '/'; | |
} |
Now everything works as expected (i.e.
/dashboard
and /dashboard/about
) at least with my minimal testing.
This is surely not the final solution as the dev server needs those lines and I guess the other adapters need them as well...
I got one step further by adding the base url to the request before passing it to the handler
:
app.use('/dashboard', (req, res, next) => {
let requestProxy = new Proxy(req, {
get(target, property) {
if (property === 'url') {
return target.baseUrl + (target.url === '/' ? '' : target.url);
}
return target[property];
},
});
handler(requestProxy, res, next);
});
Now the ssr
function works correctly (because it strips the basepath we just added) but the static files are not correctly served (because sirv does not strip the basepath) as @bundabrg also noted in #3726 (comment)
Originally posted by @fehnomenal in #3726 (comment)
adapter-node
base path configurable via environment variableadapter-node
base path configurable via environment variable
Anyone have any workarounds to this issue? Its blocking me for dynamic path deployments if i dont know the base at build time |
Same here |
I found this to work:
Oh wait a second. I think I fixed it. If I reply below, then know that I've "fixed" it. If not, then try using this in your code. |
nvm, it "works" but it causes like 100 recursive definition errors which (depending on the environment) could cause the |
Ok, so I found another solution. So, for this method, you will need
This works. But this is a work around, not a fix. |
When generating a static site we ultimately will be placing it either in the correct folder OR preferably behind a load-balancing reverse proxy that strips off the prefix and have it served from the root. So the prefix should not exist in the build folder at all but the code will need to know to add the prefix when referring to assets.
When generating a dynamic site it can be passed environment variables (or perhaps read a config file) where it gets its base prefix. In the same way the site could exist behind a reverse proxy that strips off the prefix OR it'll handle the prefix itself. It matters not as this is an implementation detail of the adapter. The code needs to know to add the prefix when referring to assets and presumably when doing SSR fetching it'll need to know to add/remove the prefix as necessary.
adapter-node
usesPolka
to serve its assets, executed with the following code:handler
is provided as:The issue is that
ssr
will strip offbase
from the beginning of the URL but the threeserve
calls do not. Thessr
function IMHO should not be doing this and instead everything should be mounted at thepolka().use()
call, something like this:where
BASE_PATH
would be set either by reading the config file or come in from an environment variable.This way if I have a reverse proxy that strips prefixes I can have
BASE_PATH
set to '' but pass the actual base through a header likeX-Forwarded-Prefix
for when building URL's.If I don't strip the prefix, then I can set
BASE_PATH
to the prefix so its handled inside Polka instead but otherwise the rest of the code remains the same.Anyway, that's my 2c.
Originally posted by @bundabrg in #3726 (comment)
This overlaps a bit with #595
The text was updated successfully, but these errors were encountered: