search

sst / open-next

Open source Next.js serverless adapter
https://open-next.js.org
MIT License
3.86k stars 116 forks source link

RSC requests fail because of `.rsc` suffix when using a proxy #494

Closed michael-kleemann closed 2 weeks ago

michael-kleemann commented 2 weeks ago

We are facing a strange behavior when using a proxy before our open-next app. RSC requests for another route fail because the suffix .rsc is being appended to the dynamic route id. This breaks client side routing right now.

This error does not occur with a proxy on a regular next js app hosted on Vercel. To demonstrate this quite complex scenario i've setup an example.

Here is a next js app hosted on Vercel which serves as a simple proxy with two routes. https://proxy-showcase.vercel.app/proxy-standard-target https://proxy-showcase.vercel.app/proxy-opennext-target image Source: https://github.com/michael-kleemann/proxy-showcase

The first route points to a next js app hosted on Vercel. Clientside routing is working perfectly. Source: https://github.com/michael-kleemann/proxy-standard-target

The second route points to an open-next app hosted on AWS via SST with open-next 3.1.0. The source code is exactly the same but client side routing is broken. When clicking a link you can see that data cannot be fetched as a wrong id is forwarded to the dynamic route. The invalid id is being displayed in the error case. It is already visible when looking at the RSC request in the network tab. image Source: https://github.com/michael-kleemann/proxy-opennext-target

I would expect that open-next should behave exactly like the standard next js app.

conico974 commented 2 weeks ago

I'm pretty sure this is an issue with vercel itself. There is nothing that i can think of in OpenNext that would append .rsc to your request, the most likely given that the rewrite are done on vercel is that vercel is detecting it's an rsc request and adding .rsc to it. It works on vercel because that's how vercel differentiate rsc request from html one. The easiest fix is probably to rewrite this in the middleware of your OpenNext app to just remove the .rsc

michael-kleemann commented 2 weeks ago

We experienced that the assumption pretty much was right. At the end we figured out that our rewriting rules should be applied in the beforeFiles section instead of fallback that we used. Fallback is applied quite late in the middleware chain which caused some manipulations on the RSC requests. https://nextjs.org/docs/app/building-your-application/routing/middleware#matching-paths