Open WHenderson opened 5 years ago
Is it possible to use node-fetch
(which is what this.fetch
calls internally on the server) to make a request to a named pipe? What would that look like?
This is well outside my wheel house. I'm hoping someone else will have some clues. I've been searching the web for clues here, but it just seems to be quite niche. Azure will be the biggest install base for this kind of issue, but I've no experience there and don't know where to begin.
Mostly I just thought I could save someone a headache if they found themselves in a similar situation.
Did anyone ever resolve this? I ran into this same issue. Can't create a json API because of this issue.
I have been trying to use iisnode to run a sapper project on a local IIS instance and was getting failures on pages which use prefetch modules. Notably, the prefetch was failing when navigating to a page directly via the browser rather than from links within the application.
Further investigation revealed that iisnode set "process.env.PORT" to something like "\.\pipe\GUID". This is a named pipe which express/polka seem happy to bind to, but which some internal sapper code isn't equipped to handle. Specifically: runtime/server.mjs/get_page_handler/preload_context.fetch
It assumes that the site is listening on
http://127.0.0.1:${process.env.PORT}
which in this case it isn't.My fix/hack has been to modify my server.js and add this line right before creating my polka/express app:
This works for me but it will likely not work for Azure which is the primary use case for iisnode. I believe all nodejs apps run via iisnode in azure?
I was also wondering if this is the most efficient way of handling these internal requests. It may be better to use the .handler methods from polka/express directly, or allow some facility to override the preload_context.
Thanks in advance!