rsnext/errors/returning-response-body-in-middleware.md
Damien Simonin Feugas bf089562c7
feat(middleware)!: forbids middleware response body (#36835)
_Hello Next.js team! First PR here, I hope I've followed the right practices._

### What's in there?

It has been decided to only support the following uses cases in Next.js' middleware:
- rewrite the URL (`x-middleware-rewrite` response header)
- redirect to another URL (`Location` response header)
- pass on to the next piece in the request pipeline (`x-middleware-next` response header)

1. during development, a warning on console tells developers when they are returning a response (either with `Response` or `NextResponse`).
2. at build time, this warning becomes an error.
3. at run time, returning a response body will trigger a 500 HTTP error with a JSON payload containing the detailed error.

All returned/thrown errors contain a link to the documentation.

This is a breaking feature compared to the _beta_ middleware implementation, and also removes `NextResponse.json()` which makes no sense any more.

### How to try it?
- runtime behavior: `HEADLESS=true yarn jest test/integration/middleware/core`
- build behavior : `yarn jest test/integration/middleware/build-errors`
- development behavior: `HEADLESS=true yarn jest test/development/middleware-warnings`

### Notes to reviewers

The limitation happens in next's web adapter. ~The initial implementation was to check `response.body` existence, but it turns out [`Response.redirect()`](https://github.com/vercel/next.js/blob/canary/packages/next/server/web/spec-compliant/response.ts#L42-L53) may set the response body (https://github.com/vercel/next.js/pull/31886). Hence why the proposed implementation specifically looks at response headers.~
`Response.redirect()` and `NextResponse.redirect()` do not need to include the final location in their body: it is handled by next server https://github.com/vercel/next.js/blob/canary/packages/next/server/next-server.ts#L1142

Because this is a breaking change, I had to adjust several tests cases, previously returning JSON/stream/text bodies. When relevant, these middlewares are returning data using response headers.

About DevEx: relying on AST analysis to detect forbidden use cases is not as good as running the code.
Such cases are easy to detect:
```js
new Response('a text value')
new Response(JSON.stringify({ /* whatever */ })
```
But these are false-positive cases:
```js
function returnNull() { return null }
new Response(returnNull())

function doesNothing() {}
new Response(doesNothing())
```
However, I see no good reasons to let users ship middleware such as the one above, hence why the build will fail, even if _technically speaking_, they are not setting the response body. 



## Feature

- [x] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR.
- [ ] Related issues linked using `fixes #number`
- [x] Integration tests added
- [x] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [x] Errors have helpful link attached, see `contributing.md`

## Documentation / Examples

- [x] Make sure the linting passes by running `yarn lint`
2022-05-19 22:02:20 +00:00

2.5 KiB

Returning response body in middleware

Why This Error Occurred

Your middleware function returns a response body, which is not supported.

Letting middleware respond to incoming requests would bypass Next.js routing mechanism, creating an unecessary escape hatch.

Possible Ways to Fix It

Next.js middleware gives you a great opportunity to run code and adjust to the requesting user.

It is intended for use cases like:

  • A/B testing, where you rewrite to a different page based on external data (User agent, user location, a custom header or cookie...)

    export function middleware(req: NextRequest) {
      let res = NextResponse.next()
      // reuses cookie, or builds a new one.
      const cookie = req.cookies.get(COOKIE_NAME) ?? buildABTestingCookie()
    
      // the cookie contains the displayed variant, 0 being default
      const [, variantId] = cookie.split('.')
      if (variantId !== '0') {
        const url = req.nextUrl.clone()
        url.pathname = url.pathname.replace('/', `/${variantId}/`)
        // rewrites the response to display desired variant
        res = NextResponse.rewrite(url)
      }
    
      // don't forget to set cookie if not set yet
      if (!req.cookies.has(COOKIE_NAME)) {
        res.cookies.set(COOKIE_NAME, cookie)
      }
      return res
    }
    
  • authentication, where you redirect to your log-in/sign-in page any un-authenticated request

    export function middleware(req: NextRequest) {
      const basicAuth = req.headers.get('authorization')
    
      if (basicAuth) {
        const auth = basicAuth.split(' ')[1]
        const [user, pwd] = atob(auth).split(':')
        if (areCredentialsValid(user, pwd)) {
          return NextResponse.next()
        }
      }
    
      return NextResponse.redirect(`/login?from=${req.nextUrl.pathname}`)
    }
    
  • detecting bots and rewrite response to display to some sink

    export function middleware(req: NextRequest) {
      if (isABotRequest(req)) {
        // Bot detected! rewrite to the sink
        const url = req.nextUrl.clone()
        url.pathname = '/bot-detected'
        return NextResponse.rewrite(url)
      }
      return NextResponse.next()
    }
    
  • programmatically adding headers to the response, like cookies.

    export function middleware(req: NextRequest) {
      const res = NextResponse.next(null, {
        // sets a custom response header
        headers: { 'response-greetings': 'Hej!' },
      })
      // configures cookies
      response.cookies.set('hello', 'world')
      return res
    }