Skip to content

Commit 080e1b3

Browse files
icyJosephcursoragentvercel[bot]
authored
Accept header content negotiation (#90607)
<!-- Thanks for opening a PR! Your contribution is much appreciated. To make sure your PR is handled as smoothly as possible we request that you follow the checklist sections below. Choose the right checklist for the change(s) that you're making: ## For Contributors ### Improving Documentation - Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? Added a new "Content negotiation" subsection to the Backend For Frontend (BFF) guide. Updated the `related` links in the frontmatter of the BFF guide to include "rewrites". ### Why? To document how to implement content negotiation using Next.js rewrites and Route Handlers, specifically for serving different content types (e.g., Markdown) based on the `Accept` header. This includes explaining the role of the `Vary: Accept` header for correct caching behavior. ### How? A new subsection was added to `docs/01-app/02-guides/backend-for-frontend.mdx`. The section includes a `next.config.js` rewrite example using `has` to match the `Accept` header. A corresponding Route Handler example (`app/docs/md/[...slug]/route.ts`) demonstrates serving Markdown content. The documentation explains the `Vary: Accept` header and its implications for caching. The `related` links in the frontmatter were updated to point to the rewrites documentation. Closes NEXT- Fixes # --> --- [Slack Thread](https://vercel.slack.com/archives/C07BS1WEYAZ/p1772118031912479?thread_ts=1772118031.912479&cid=C07BS1WEYAZ) <p><a href="https://cursor.com/agents/bc-2c93f44d-958d-5c0b-abe0-a2b36aa76f19"><picture><source media="(prefers-color-scheme: dark)" srcset="https://cursor.com/assets/images/open-in-web-dark.png"><source media="(prefers-color-scheme: light)" srcset="https://cursor.com/assets/images/open-in-web-light.png"><img alt="Open in Web" width="114" height="28" src="https://cursor.com/assets/images/open-in-web-dark.png"></picture></a>&nbsp;<a href="https://cursor.com/background-agent?bcId=bc-2c93f44d-958d-5c0b-abe0-a2b36aa76f19"><picture><source media="(prefers-color-scheme: dark)" srcset="https://cursor.com/assets/images/open-in-cursor-dark.png"><source media="(prefers-color-scheme: light)" srcset="https://cursor.com/assets/images/open-in-cursor-light.png"><img alt="Open in Cursor" width="131" height="28" src="https://cursor.com/assets/images/open-in-cursor-dark.png"></picture></a>&nbsp;</p> --------- Co-authored-by: Cursor Agent <[email protected]> Co-authored-by: Joseph <[email protected]> Co-authored-by: vercel[bot] <35613825+vercel[bot]@users.noreply.github.com>
1 parent fe2f1e4 commit 080e1b3

1 file changed

Lines changed: 101 additions & 1 deletion

File tree

docs/01-app/02-guides/backend-for-frontend.mdx

Lines changed: 101 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -4,10 +4,11 @@ nav_title: Backend for Frontend
44
description: Learn how to use Next.js as a backend framework
55
related:
66
title: API Reference
7-
description: Learn more about Route Handlers and Proxy
7+
description: Learn more about Route Handlers, Proxy, and Rewrites
88
links:
99
- app/api-reference/file-conventions/route
1010
- app/api-reference/file-conventions/proxy
11+
- app/api-reference/config/next-config-js/rewrites
1112
---
1213

1314
Next.js supports the "Backend for Frontend" pattern. This lets you create public endpoints to handle HTTP requests and return any content type—not just HTML. You can also access data sources and perform side effects like updating remote data.
@@ -178,6 +179,105 @@ export async function GET(request) {
178179

179180
Sanitize any input used to generate markup.
180181

182+
### Content negotiation
183+
184+
You can use [rewrites](/docs/app/api-reference/config/next-config-js/rewrites) with header matching to serve different content types from the same URL based on the request's `Accept` header. This is known as [content negotiation](https://developer.mozilla.org/en-US/docs/Web/HTTP/Content_negotiation).
185+
186+
For example, a documentation site might serve HTML pages to browsers and raw Markdown to AI agents from the same `/docs/…` URLs.
187+
188+
**1. Configure a rewrite that matches the `Accept` header:**
189+
190+
```js filename="next.config.js"
191+
module.exports = {
192+
async rewrites() {
193+
return [
194+
{
195+
source: '/docs/:slug*',
196+
destination: '/docs/md/:slug*',
197+
has: [
198+
{
199+
type: 'header',
200+
key: 'accept',
201+
value: '(.*)text/markdown(.*)',
202+
},
203+
],
204+
},
205+
]
206+
},
207+
}
208+
```
209+
210+
When a request to `/docs/getting-started` includes `Accept: text/markdown`, the rewrite routes it to `/docs/md/getting-started`. A Route Handler at that path returns the Markdown response. Clients that do not send `text/markdown` in their `Accept` header continue to receive the normal HTML page.
211+
212+
**2. Create a Route Handler for the Markdown response:**
213+
214+
```ts filename="app/docs/md/[...slug]/route.ts" switcher
215+
import { getDocsMd, generateDocsStaticParams } from '@/lib/docs'
216+
217+
export async function generateStaticParams() {
218+
return generateDocsStaticParams()
219+
}
220+
221+
export async function GET(_: Request, ctx: RouteContext<'/docs/md/[...slug]'>) {
222+
const { slug } = await ctx.params
223+
const mdDoc = await getDocsMd({ slug })
224+
225+
if (mdDoc == null) {
226+
return new Response(null, { status: 404 })
227+
}
228+
229+
return new Response(mdDoc, {
230+
headers: {
231+
'Content-Type': 'text/markdown; charset=utf-8',
232+
Vary: 'Accept',
233+
},
234+
})
235+
}
236+
```
237+
238+
```js filename="app/docs/md/[...slug]/route.js" switcher
239+
import { getDocsMd, generateDocsStaticParams } from '@/lib/docs'
240+
241+
export async function generateStaticParams() {
242+
return generateDocsStaticParams()
243+
}
244+
245+
export async function GET(_, { params }) {
246+
const { slug } = await params
247+
const mdDoc = await getDocsMd({ slug })
248+
249+
if (mdDoc == null) {
250+
return new Response(null, { status: 404 })
251+
}
252+
253+
return new Response(mdDoc, {
254+
headers: {
255+
'Content-Type': 'text/markdown; charset=utf-8',
256+
Vary: 'Accept',
257+
},
258+
})
259+
}
260+
```
261+
262+
The [`Vary: Accept`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary) response header tells caches that the response body depends on the `Accept` request header. Without it, a shared cache could serve a cached Markdown response to a browser (or vice versa). Most hosting providers already include the `Accept` header in their cache key, but setting `Vary` explicitly ensures correct behavior across all CDNs and proxy caches.
263+
264+
`generateStaticParams` lets you pre-render the Markdown variants at build time so they can be served from the edge without hitting the origin server on every request.
265+
266+
**3. Test it with `curl`:**
267+
268+
```bash
269+
# Returns Markdown
270+
curl -H "Accept: text/markdown" https://example.com/docs/getting-started
271+
272+
# Returns the normal HTML page
273+
curl https://example.com/docs/getting-started
274+
```
275+
276+
> **Good to know:**
277+
>
278+
> - The `/docs/md/...` route is still directly accessible without the rewrite. If you want to restrict it to only serve via the rewrite, use [`proxy`](/docs/app/api-reference/file-conventions/proxy) to block direct requests that don't include the expected `Accept` header.
279+
> - For more advanced negotiation logic, you can use [`proxy`](/docs/app/api-reference/file-conventions/proxy) instead of rewrites for more flexibility.
280+
181281
### Consuming request payloads
182282

183283
Use Request [instance methods](https://developer.mozilla.org/en-US/docs/Web/API/Request#instance_methods) like `.json()`, `.formData()`, or `.text()` to access the request body.

0 commit comments

Comments
 (0)