`next/font` interferes with header links from middleware.

[zenzen-sol]

Link to the code that reproduces this issue

https://github.com/zenzen-sol/next-reproduction-template/tree/sol/repro-001-next-15-broken

To Reproduce

1. pnpm i && pnpm run dev
2. Reload http://localhost:3000 in a browser.
3. Check the response header links in dev tools.

Examples:

• ✅ Last working release (NextJS 14.3.0-canary.42): https://github.com/zenzen-sol/next-reproduction-template/tree/sol/repro-001-next-14-3-0-canary-42-working
• 🙅🏻 First broken release (NextJS 14.3.0-canary.43): https://github.com/zenzen-sol/next-reproduction-template/tree/sol/repro-001-next-14-3-0-canary-43-broken
• ✅ Working without next/font (NextJS 15.0.0-rc.0): https://github.com/zenzen-sol/next-reproduction-template/tree/sol/repro-001-next-15-working

Current vs. Expected behavior

The next-intl library's middleware injects "alternate" links into the response header for SEO purposes. At the same time, next/font injects "preload" header links into the response header. Both sets of links should appear in the response header. This was working correctly in Next 14.

Since NextJS 14.3.0-canary.43 and 15.0.0-canary.0, the "alternate" links from next-intl are no longer present when next/font is used.

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 23.6.0: Fri Jul  5 17:53:24 PDT 2024; root:xnu-10063.141.1~2/RELEASE_ARM64_T6020
  Available memory (MB): 32768
  Available CPU cores: 12
Binaries:
  Node: 20.11.1
  npm: 10.2.4
  Yarn: 3.6.1
  pnpm: 9.7.1
Relevant Packages:
  next: 15.0.0-rc.0 // Latest available version is detected (15.0.0-rc.0).
  eslint-config-next: N/A
  react: 19.0.0-rc-19bd26be-20240815
  react-dom: 19.0.0-rc-19bd26be-20240815
  typescript: 5.5.4
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

Font (next/font), Internationalization (i18n), Metadata, Middleware

Which stage(s) are affected? (Select all that apply)

next dev (local), Vercel (Deployed)

Additional context

I tested my reproduction against canary releases back to 14.3.0-canary.0. This issue first appears in v14.3.0-canary.43, and is not present in 14.3.0-canary.42.

If I had to guess, the issue is related to the changes made to packages/next/src/server/app-render/app-render.tsx in that prerelease.