Showing data dump in the type text/x-component on the UI

[nandap4790]

Summary

When I do a client side navigation from Page A to Page B using Link component, the page renders correctly.
When I check the network request, the type of the content being text/x-component and the response being:

0:[["children",["slug","/slug","oc"], in this format.

Now when I refresh the page, I get:
0:[["children",["slug","/slug","oc"], being dumped on the UI in place of HTML.

I suspect this to be a cache issue, because when a query param is added the page renders perfectly and when I bypass the cache it renders correctly.

This does not happen there is a server navigation.

Can someone shed some light on this ?

Additional information

No response

Example

No response

[jihu]

Hi,

We are actually struggling with the same problem. Turns out that Next.js does some magic with the "vary" header, which instructs caching layers/services how to cache the content. If your caching layer, like a CDN, doesn't handle the vary header, or handles it incorrectly, then this can happen. I'm haven't found any official documentation on this, but I found this discussion that might help you:

https://www.reddit.com/r/nextjs/comments/13bizz0/hosting_ssr_site_with_cache_control/

[cizz3007]

I am experiencing this problem.
I'm hoping for a solution soon.

[vinizinmoraes]

Were you able to find a solution for this issue? We are having this problem with cloudfare caching.

[Protino]

Would disabling text/x-component content type on CDN resolve this issue?

Were you able to find any solution?

[shockbs]

I'm looking for a solution too! It serves either text/x-component or application/octet-stream with a rsc txt content instead of html :(
and i have to clear cache for that path on cloudflare to fix it, every time for every single page

[yongshun950824]

Having the same isue as well. But for my case it happens after migrate from CloudFlare to Imperva. And previously in CloudFlare, not face this issue. As I know the attempt that managed by infra & Imperva team is to disable caching for certain URL path/whole website, this issue is "temporary" resolved, but they mentioned that this is not a good approach.

[Protino]

Since we use Akamai, we solved this by just disabling 'Remove vary header'

[seloElo]

Found out I had the same issues on SSR pages! Had to remove the caching rule of thoses pages in cloudflare...

[ranzwertig]

We’re encountering the same issue while using Cloudflare. Since Cloudflare doesn’t support the Vary header, we initially assumed that could be the root cause. However, based on this comment from @timneutkens, it seems the introduction of the _rsc query parameter should address this:

Please provide a reproduction in a new issue. We've added a query string parameter to the end of the request for the RSC payload, so it's hard to say why you'd still see this without being able to investigate the application.

Does this mean there's a bug? My understanding from the comment is that all RSC requests should now include the _rsc parameter, which should make the Vary header unnecessary.

[hanihaghshenas]

Has anyone made any progress on resolving this issue? We've been experiencing an identical problem for the past two days with the following technical details:

Environment:

• Using Cloudflare CDN
• RSC requests with query strings (?_rsc=...)
• Vary headers configured as: RSC, Next-Router-State-Tree, Next-Router-Prefetch, Accept-Encoding

Issue Description:
When loading the homepage, the initial document request returns Content-Type: text/x-component instead of the expected text/html. This results in raw text being displayed in the browser rather than properly rendered HTML, which appears to be the response content from an RSC (React Server Components) request.

Current Workaround:
We've been able to temporarily resolve the issue by purging the Cloudflare cache, but the problem consistently reoccurs within a few hours.

Question:
Has anyone identified the root cause or found a permanent solution? Any insights into why RSC responses might be getting cached and served as the main document would be greatly appreciated.

[ReesMorris]

We just ran into this issue as well.

We have a Google Cloud CDN in front of our frontends which we just upgraded to 15.3.2 (from 15.1.4), and it was alternating between returning an RSC Payload (1:"$Sreact.fragment"... with Content-Type: text/x-component) and the actual HTML page content.

For our case, I believe this was caused by changes to the Vary HTTP response header, introduced by #77797, and reverted by #79426.

To confirm this, I created a fresh create-next-app project, inspecting the Vary header in the responses from next dev across versions surrounding the commit and its reversion:

• 15.3.0-canary.36 (released before 77797 was merged):
  • The Vary header included RSC, Next-Router-State-Tree, Next-Router-Prefetch, Next-Router-Segment-Prefetch, Accept-Encoding.
• 15.3.0-canary.37 (which merged 77797):
  • The Vary header only had Accept-Encoding.
• 15.4.0-canary.48 (the last version before it is reverted in 79426):
  • The Vary header was still only Accept-Encoding.
• 15.4.0-canary.49 (which reverts 77797):
  • The Vary header contains RSC, Next-Router-State-Tree, Next-Router-Prefetch, Next-Router-Segment-Prefetch, Accept-Encoding.

My understanding is that this allowed our CDN (and likely browser caches) to incorrectly serve an RSC payload (which might have been cached from a client-side navigation or prefetch, or an SSR fallback). We upgraded one of our staging environments to ^15.4.0-canary.53, and haven't noticed this reoccuring.

Although our CDN did have includeQueryString enabled, my guess is that #79346 was causing issues for us since we need to do some redirection tricks with next-intl.

[asfopoo]

Having the same issue. I disabled the cache in cloudfront :( for now to get it working properly but would like a real solution so I can go back re-enable the cache

I was on v15.3.0 updating to 15.4.0-canary.49 did not fix the issue for me