nodejs app in azure windows app service with iisnode enters redirect loop

Question

nodejs app in azure windows app service with iisnode enters redirect loop

Xecrets 5

After successful deploy, no code changes, the service only responds to requests handled by IIS directly, such as static .txt files. When attempting to access the site proper, the site responds with a redirect to pipe/d63ddeca-6078-4eee-bde1-d98e830f0efc, which in turn responds with an additional redirect to pipe/d63ddeca-6078-4eee-bde1-d98e830f0efc/pipe/d63ddeca-6078-4eee-bde1-d98e830f0efc etc ad inifinitum, i.e. a redirect loop, until the server says stop because the URL is too long.

It seems to be something internal to Azure is broken, but I can find no logs that says any more than what I say above. I have verified the web.config (also unchanged when the issue appeared). There is essentially little or no traffic, so it's unlikely to be a case of too many requests for node. I've checked quotas, logs, and also temporarily upgraded to S1 (it's a test site running in F1 normally), with the same problem.

Lex Li (Microsoft) 6,037 Reputation points Microsoft Employee

2023-08-30T01:06:10.25+00:00

Can you give HttpPlatformHandler a try? https://halfblood.pro/running-nodejs-web-apps-on-iis-with-httpplatformhandler/
Xecrets 5 Reputation points

2023-08-30T06:19:48.7833333+00:00

Thank you Lex Li, but it's too big a thing to change, and it's hard to oversee the consequences. Also, I found that my initial report was inaccurate. The problem is in fact (of course) connected to a change, the reason it appeared to be a bigger problem was due to the aggressive default caching configured. In the end it turns out to be something changed with Next.js 13 App routing, causing it for some reason not to start the server properly with iisnode. I have no idea what the real problem is, but changing how the server is started to use the current version of 'start-server.ts' in the Next.js distribution did "fix" the problem - however at the loss of the capability to inject your own request handler. Also, removing 'app.prepare()' from the previous code, which was based on the Pages router example documented on the Next.js web site made the problem go away, but I can't say just what the consequences of that would be either. Apparently the idea of Next.js is to use the middleware method to add processing to requests, the problem there being that in a middleware handler you're restricted to what's available in the edge runtime. All in all, I am getting a bit worried about deploying Next.js outside of Vercel. The documentation is non-existant, the framework moves forward at an aggressive pace with a lot of problems being constantly caused and fixed, and some not really thought-through sweeping changes are introduced, such as the above and also the whole App routing, causing developer difficulty due to suddenly having potentially tons of files all named 'page.js' etc, it's already known to be inconvenient since you have to see the whole path in tools in order to understand what you're looking at. Not a great idea, and a mistake already made in other frameworks.
Lex Li (Microsoft) 6,037 Reputation points Microsoft Employee

2023-08-30T08:11:55.78+00:00

I don’t think Next.js supports IIS very well as its official documentation missed the relevant sections (the last time I checked). (Other frameworks like Nuxt.js officially supports IIS and has good documentation to get you started.)

To investigate further and possibly fix this issue, you do need first hand assistance from the authors of that web framework.
Xecrets 5 Reputation points

2023-08-30T08:36:17.4566667+00:00

The problem is not so much that Next.js doesn't support IIS as a first class citizen, it's that IIS/Windows does not support Node.js as a first class citizen so we have to resort to things like iisnode. Then again, you are right in that there is absolutely no mention of how to actually run Next.js on IIS in their documentation, which is certainly possible albeit a bit cumbersome and possibly not super well performant.

1 answer

Your answer

Lex Li (Microsoft) 6,037 Reputation points Microsoft Employee

2023-08-30T01:06:10.25+00:00

Can you give HttpPlatformHandler a try? https://halfblood.pro/running-nodejs-web-apps-on-iis-with-httpplatformhandler/
Xecrets 5 Reputation points

2023-08-30T06:19:48.7833333+00:00

Thank you Lex Li, but it's too big a thing to change, and it's hard to oversee the consequences. Also, I found that my initial report was inaccurate. The problem is in fact (of course) connected to a change, the reason it appeared to be a bigger problem was due to the aggressive default caching configured. In the end it turns out to be something changed with Next.js 13 App routing, causing it for some reason not to start the server properly with iisnode. I have no idea what the real problem is, but changing how the server is started to use the current version of 'start-server.ts' in the Next.js distribution did "fix" the problem - however at the loss of the capability to inject your own request handler. Also, removing 'app.prepare()' from the previous code, which was based on the Pages router example documented on the Next.js web site made the problem go away, but I can't say just what the consequences of that would be either. Apparently the idea of Next.js is to use the middleware method to add processing to requests, the problem there being that in a middleware handler you're restricted to what's available in the edge runtime. All in all, I am getting a bit worried about deploying Next.js outside of Vercel. The documentation is non-existant, the framework moves forward at an aggressive pace with a lot of problems being constantly caused and fixed, and some not really thought-through sweeping changes are introduced, such as the above and also the whole App routing, causing developer difficulty due to suddenly having potentially tons of files all named 'page.js' etc, it's already known to be inconvenient since you have to see the whole path in tools in order to understand what you're looking at. Not a great idea, and a mistake already made in other frameworks.
Lex Li (Microsoft) 6,037 Reputation points Microsoft Employee

2023-08-30T08:11:55.78+00:00

I don’t think Next.js supports IIS very well as its official documentation missed the relevant sections (the last time I checked). (Other frameworks like Nuxt.js officially supports IIS and has good documentation to get you started.)

To investigate further and possibly fix this issue, you do need first hand assistance from the authors of that web framework.
Xecrets 5 Reputation points

2023-08-30T08:36:17.4566667+00:00

The problem is not so much that Next.js doesn't support IIS as a first class citizen, it's that IIS/Windows does not support Node.js as a first class citizen so we have to resort to things like iisnode. Then again, you are right in that there is absolutely no mention of how to actually run Next.js on IIS in their documentation, which is certainly possible albeit a bit cumbersome and possibly not super well performant.

Answer 1

@Xecrets Hello! It seems like you were having trouble with a Node.js app in Azure Windows App Service with iisnode that was entering a redirect loop. I'm glad to hear that you were able to identify the root cause of the issue and find a workaround. It sounds like the problem was related to a change in Next.js 13 App routing, which caused the server to not start properly with iisnode. While Next.js may not support IIS as well as other frameworks like Nuxt.js, it is still possible to run Next.js on IIS with some effort. If you have any further questions or concerns, please don't hesitate to ask.

Share via

nodejs app in azure windows app service with iisnode enters redirect loop

1 answer

Your answer