RFC: Middleware

[leerob]

The Middleware API is now stable with Next.js 12.2. Learn more about the release or view the upgrade guide.

---

Goals

• Share and reuse logic that is repeatable for every request.
• Build on top of existing Web Standard APIs, with a strict runtime¹.
• Self-serve advanced routing requirements.
• Execute dynamic code without opting out of caching.
• Provide code over configuration to Next.js developers.

Non-Goals

• Support the entirety of the Node.js runtime inside Middleware.
• Have an API similar to Node.js (e.g. req and res).

Background

When developers spin up their own solutions using servers, they can influence the request lifecycle with as much middleware as they need (e.g.: by using app.use() in Express.js. Currently, Next.js users are constrained by:

• Lack of flexibility with configuration (headers, rewrites, redirects, etc.) which support many scenarios, but don't work for advanced use-cases.
• The learning curve and DX of ever-growing configuration capabilities, bringing a YAML configuration-like problem to Next.js.

Proposal

We propose to introduce a native capability in Next.js to define Middleware, allowing for complete flexibility of the upstream request as well as the response. Middleware would have the ability to add headers to the next request, as well as to the response, and more.

Middleware could be used for anything that shares logic for a set of pages: authentication, bot protection, redirects, handling unsupported browsers, server-side analytics, logging, etc.

To use Middleware with Next.js, you would export a function middleware inside a file pages/_middleware.js²:

// pages/_middleware.js

export function middleware (event) {
  event.respondWith(new Response('Hello world'))
}

For example, you could implement basic authentication as follows:

// pages/_middleware.js

export function middleware (event) {
  const auth = event.request.headers.get('authorization') ?? ''
  const [user, pwd] = atob(auth.split(' ')[1]).split(':')

  if (!(user === '4dmin' && pwd === 'testpwd123')) {
    event.respondWith(
      new Response('Unauthorized', {
        headers: { 'WWW-Authenticate': 'Basic realm="Secure Area"' },
        status: 401,
      })
    )
  }
}

Or more easily support A/B testing:

// pages/_middleware.js

export function middleware (event) {
  let bucket = event.request.cookies.bucket
  if (bucket) {
    return event.respondWith(Response.rewrite(`/features/${bucket}`))
  }

  bucket = Math.random() >= 0.5 ? 'a' : 'b'
  const response = Response.rewrite(`/features/${bucket}`)
  response.cookie('version', bucket)
  return event.respondWith(response)
}

Users can define Middleware by providing _middleware at any level in the file tree under pages/. For example, if you had a nested Middleware inside /dashboard, the order of execution would be as follows:

1. pages/_middleware.js would run first, on every request
2. pages/dashboard/_middleware.js would run second, only for pages under /dashboard

// pages/dashboard/_middleware.js

// This middleware only applies to nested routes under /dashboard
//   /dashboard -> Yes
//   /dashboard/user -> Yes
//   /dashboard/user/settings -> Yes
//   / -> No
export function middleware (event) {
  const next = Response.next()
  next.headers.set('Permissions-Policy', 'camera=(), microphone=()')
  event.respondWith(next)
}

Footnotes

1. Since Middleware could run for each request, including static pages, we want to ensure it will stay fast over time. This requires limiting the runtime inside Middleware to and not supporting the entirety of the Node.js. You would still be able to use ES Modules that did not rely on Node.js APIs, as well as Web Standard APIs. ↩

2. In the future, we'd like to expose a way to use the same runtime as Middleware for getStaticProps, getStaticPaths, getServerSideProps, and API Routes. ↩

[dwalkr]

This looks great! Does event.respondWith(Response.next()) fall back to the standard response handler (getStaticProps, getServerSideProps, static pages etc) if not altered by any further middleware?

Would it be possible, for example, to add arbitrary data to the context object that can subsequently be accessed in a getStaticProps handler?

[leerob]

Correct. In the future, we'd like to expose a way to use the same runtime as Middleware for getStaticProps, getStaticPaths, getServerSideProps, and API Routes – which I believe solves your question.

[hypervillain]

@leerob does this mean that this won't be available in the first version of middlewares?

[patryk-smc]

Fascinating! Will it run only before response, or after response as well? For server-side analytics, it doesn't make sense to call some API, before the page has been seen.

[leerob]

You'll be able to respond inside Middleware and then process after for things like server-side analytics 👍

[matthewiiv]

This is brilliant!

[2color]

pages/_middleware.js would run first, on every request

Does this include statically generated pages with GetStaticProps, SSR pages, and API routes?

[flybayer]

Given it works for static pages and the no-Node.js API support, it looks like you are intending _middleware to run on an edge function, correct?

[flybayer]

I was right 😎

[patryk-smc]

Will it run just on initial page load, or on page transitions with next/router as well? I would like to run certain middleware just on initial page load, and some other on each page load (navigated via next/router).

[darenh]

Get it to work on page transitions?

[aiji42]

I am eagerly awaiting this feature!

I'm developing a plugin for A/B testing called next-with-split. https://github.com/aiji42/next-with-split
The workings of this plugin are very close to your philosophy.

This plugin creates pages/_split-challenge.js and directs requests to this file with rewrite rules. Then, by running a reverse proxy with getServerSideProps in the file, it is able to separate the content.

If the middleware is supported natively, it can deliver content more flexibly.

[aiji42]

The _middleware.js should be useful in a variety of situations other than the A/B testing and basic authentication examples mentioned earlier.
For example...

• Access control by IP address (x-forwared-for)
• Access control using credentials from IDaaS such as firebase and auth0 (tokens need to be shared with cookies)
• Eliminate harmful bot crawlers
• Differentiation of content between desktop and mobile devices by user agent

This should be a great solution to the week point of Jamstack! 🥳

[weyert]

Yeah, hopefully, I can use it, to add Prometheus metrics to determine how long it taken to render the page on the server side. Currently there isn’t a good story as you can’t access the route path in a custom server’s middleware

[leerob]

Exactly! Yeah, A/B testing is a great application of Middleware. I'll create an example using Middleware with Split 👍

[weyert]

Would this allow be to track request durations so I can expose these with Prometheus?

Currently, I am using a custom express middleware but it's impossible to get the file-based route path which makes metrics have a unnecessary high cardinality

[leerob]

Yeah, I believe so!

[matamatanot]

#30081

[flybayer]

Are you providing some type of adapter so we can easily use any existing express/connect middleware?

[leerob]

Please see this note above 👍 Given that constraint, it's not intended to be a drop-in replacement for Express middleware.

[BenjaminWFox]

If, say, I wanted a different middleware stack for my pages vs api routes is there a way to exclude the /api directory from a top level _middleware.js?

[ifonefox]

event.request has info about the request, including the url. You could use event.request.url or event.request.page.name to see if it starts with /api/, and stop the middleware from doing anything else. page.name has the route it uses (like "/api/[id]/info"), while url has the real url (like "/api/123/info"). There's also event.request.nextUrl. This is all undocumented, so I don't know which is the best option to use.

[BenjaminWFox]

Gotcha. I was playing around with the Canary branch and I couldn't find any of that info so I'm either doing it wrong or that part of the implementation isn't complete yet.

[ifonefox]

Those properties worked for me with the current canary. The best info I could find is Typescript types. The event object is a NextFetchEvent, and you can find the type info here, and its parent type here. For event.request, check out NextRequest and its parent Request

[BenjaminWFox]

Ok thanks, I see where I was getting confused. The default behavior is that it runs for every request & not just route navigation - so loading images on a page also fires the middleware...which were the logs I was seeing w/o route or page names.

Just thinking out loud, I feel like I'd rather opt-in to that much detail, but am curious if the broader user base finds it useful.

[VinayaSathyanarayana]

Hope this can handle the following use cases:
#25185
#24436
#22333
#22012

[patryk-smc]

Will it be / is it possible to pass data from middleware to _app.ts?

[leerob]

Is there a reason you're not doing everything in getServerSideProps then? Is it because you want the code to run at the edge?

[stigkj]

I guess it is because it is data that all pages need, i.e. why should it be needed to do the same thing in all pages' getServersideProps?

[willemmulder]

Is there a reason you're not doing everything in getServerSideProps then? Is it because you want the code to run at the edge?

Yes good point. The edge is nice, but when we are doing auth in it, it needs to hit the DB server anyways, and so the benefit of the edge is mostly gone I suppose...

Just to be complete: what I actually want to achieve is serving personalized pages where the large part of the page is static and only a small part is personalized. I've been going through several options in my mind. Braindump:

• Using just getServerSideProps, but that would be quite slow because the static page is quite heavy and I'd rather just do that once
• Using getStaticProps to fetch the static props and combine that with getServerSideProps to get the dynamic (user-related) props. However, unfortunately it is currently not possible to combine getStaticProps with getServerSideProps.
• Using getServerSideProps but fetch the static props from some sort of local cache. A custom-writable cache is not 'natively' supported on NextJS (or is it?) but I imagine we could generate those props during the build step (in a getStaticProps of a different page maybe) and store them as JSON files in a /cache folder. Not sure if that is possible though. Would that work?
• Using the edge .next() function to fetch the 'normal' response (which would be statically generated) and then personalize it at the edge (using some search-replace logic). That does not seem to work, because the edge function only runs before the normal server, and we cannot alter the result from the normal server. Or can we?
• Using the edge to do authentication, then redirect to /page/[userId] and then use ISR to generate a user-specific page at /page/[...userId].tsx.

The last one seems to work and we get the benefit of native caching as well. But it feels a bit odd to use ISR for user-specific pages. What do you think @leerob ?

[cleberj]

I have another use case.

I am using Nextjs to create a multibrand environment, a multitenant. Every request I need to check where the request is comming from in order to know which cms url I need to use and to set theme for UI configs.

Hence, If I can't do that with middleware, every getserversideprops, I'll need to call a api to identify the config for me which could be done only once. Not a perfomance issue, but a code to be repeated everytime.

Now, My workaround will problably be to use an express/lambda edge from aws in front of nextjs to resolve the theme.

[cleberj]

Found a Way that could help you @patryk-smc .

You can modify the header on getInitialProps, once, and use it on all other getserversidetoprops, because they shared the appContext variable for the request.

I checked and I did not find any header being public. As you would lose your ISR anyways, I think it could help us until we have this feature developed.

Does anyone know any problems I could have doing this? @leerob If you could help me to address this solution, please :)

[Manikanta-20]

Is it possible to skip middleware for particular pages(Not to validate for all the pages)?

[leerob]

Yes! You can either nest the middleware inside a folder, or add conditional logic inside the middleware to exclude routes.

[VoonnaSwaamiBabu]

yes

[cliffordfajardo]

@leerob
Will there, be support for running middleware "after" the request has successfully finished?

There are a few use cases for middleware that runs "after" the request has finished:

• reporting time it took for a route to successfully finish
• lots of specific logging cases where you might only want to run after the response has finished

Currently, is there a way to hook into the finish event on a response? 🤔

// Before middleware
export function middleware(req, ev) {
  return new Response('Hello, world!')
}

// After middleware (pseudo code where a middleware has access to response object)
export function middleware(res, ev) {
   res.on('finish', () => /* run some code 🚀*/)
}

[slevy85]

Is there a way to access and modify the response body before it is sent to the client ?

Maybe something that would look like this :

export function middleware(req, ev) {
   req.on('beforesend', (response) => /* modify response body 🚀*/)
}

Or

export async function middleware(req, ev) {
   const response = await NextResponse.render()
   // modify response
}

[stigkj]

@leerob will event.waitUntil be called after a page's content is ready to be passed to the client? I.e. will the following write out the time it took to process (call getServersideProps, render the page, etc) the page?

export async function middleware(req: NextRequest, event: NextFetchEvent) {
  const start = Date.now()

  event.waitUntil(
    (async () => {
        console.log(`Execution time: ${Date.now() - start} ms`);
      })(),
    );

  return NextResponse.next();
}

[weyert]

Yeah, never got this working. I think we need to wait for @leerob or @timneutkens to come back to us.

[ruohola]

Here's an example using waitUntil:

import type { NextFetchEvent, NextRequest } from 'next/server';

export async function middleware(req: NextRequest, event: NextFetchEvent) {
  if (req.nextUrl.pathname === '/responses/send-response') {
    const { readable, writable } = new TransformStream();

    event.waitUntil(
      (async () => {
        const writer = writable.getWriter();
        const encoder = new TextEncoder();
        writer.write(encoder.encode('Hello, world! Streamed!'));
        writer.write(encoder.encode('response'));
        writer.close();
      })(),
    );

    return new Response(readable);
  }
}

Is there a way into reading info from the response here? E.g. getting the status code that an API route sent?

[M90K7]

@leerob will event.waitUntil be called after a page's content is ready to be passed to the client? I.e. will the following write out the time it took to process (call getServersideProps, render the page, etc) the page?

export async function middleware(req: NextRequest, event: NextFetchEvent) {
  const start = Date.now()

  event.waitUntil(
    (async () => {
        console.log(`Execution time: ${Date.now() - start} ms`);
      })(),
    );

  return NextResponse.next();
}

Execution time: 0 ms

Thanks for the help but not work.

The waitUntile method is expected to wait until it returns or execute other middleware, but it does not.

The actual question is how modify response our wrap response

Project api directory like below:

/_middleware.ts
/projects/index.ts
/projects/_middleware.ts
/OTHER_API/...

Q: How wrap response of all API like { "name": "mk7" } in one /_middleware.ts to { "status": 200, "message": "success", data: { "name": "mk7" } } ?

[josh-]

We've started using middleware to add a Content-Security-Policy header to all pages within our Next app via a root pages/_middleware, however we've noticed this middleware is also applied to requests for files in public (e.g. a favicon)

We're wondering whether it is intentional that middleware is invoked for requests for files served from public as well as pages?

If so, it would be great to know what is the recommended approach to conditionally running middleware only on next page routes (and not for files fetched as part of a page, for example). @ifonefox mentions here #29750 (reply in thread) that checking req.page.name !== undefined is an option, however this isn't documented in this RFC or the middleware docs here. Alternatively, @Earle-Poole proposes checking pathname.includes('.') here #29750 (reply in thread) to achieve similar functionality.

I'd be happy to open a PR updating the middleware docs if there's a recommended approach, and to clarify whether this is intended behaviour - thanks!

[bennettdams]

As req.page is not allowed anymore for v12.2.0, does someone have a solution to find out whether the request is for a page? All other requests are now included as well. The only thing that comes to my mind is writing down all routes in the project and match the URL in the middleware, but this is a brittle solution, as a new route can easily be forgotten in this setup.

[GabenGar]

Technically all requests which aren't /api or /_next/static are page requests.

[bennettdams]

@GabenGar I don't think that is true, e.g. public assets (like /favicon.ico) or fetches to custom URLs (e.g. an external backend like /my-backend/some-data) are also intercepted by middleware.

[bryanltobing]

looking for the same solution. @bennettdams

[bennettdams]

As middleware is GA now, I feel like this is a real gap in functionality and created a feature request: #38195

[pascuflow]

Is something like _middleware on the works for api routes? I would like to define just one file with middleware instead of having to use next-connect on each route.

[icyJoseph]

I skimmed through the thread, but couldn't really find anything with regards to local development testing.

It seems that I often have to deploy our application to see problems that arise from the limited API on the edge runtime.

Simply put, how does one go about developing/testing _middleware as closely as possible to the production environment it runs on? Is it enough to npm run build and start? Is npm run dev doing the trick and I am missing something?

Thanks in advance.

[leerob]

We hear you – we're working on making this better right now! 🙏

[Emiliano-Bucci]

@leerob Sorry, but how can _middleware be tested in local? It seems that neither npm run dev or vercel dev is working. Am i missing something?

[icyJoseph]

This might be on the silly side, but is there any formal difference, between:

export const middleware = (req: NextRequest) => {
    return NextResponse.next();
};

and

export const middleware = (req: NextRequest) => {
    return undefined;
};

I thought that not calling next might not trigger downstream middleware, but that's not the case.

I ask this in the context of having some logic in the middleware that concludes that nothing ought to be done. It seems that our code base took the undefined return approach, and now I want to change it to NextResponse.next(), though there doesn't seem to be any change in behaviour.

---

Edit

If you care about how we ended up with return undefined. Back in the start of the middleware beta, our code was spread out in modules.

// we had in _middleware
if(condition) return resolveCondition()

In some other file:

// lib/helper.ts
const resolveCondition = () => {
  /* do some other stuff */ 
  return undefined;
}

Inside helper one cannot import from next/server:

next/server should not be imported outside of pages/_middleware.js. See: https://nextjs.org/docs/messages/no-server-import-in-page

So the developer tested with returning undefined, and it worked. Now that we have refactored and simplified everything inside _middleware, we carried over the return undefined.

This example also does returns nothing in certain cases, https://github.com/vercel/examples/blob/main/edge-functions/query-params-filter/pages/_middleware.ts

[GabenGar]

Why is it even an error? It gets pretty hard to write wrappers (which tend to be written in separate modules) for them with that requirement.

[icyJoseph]

I think it has to do with bundling, and we might bring into scope unsupported Node APIs, but I am guessing. I'd agree that the rule is harsh, but I go with it because this is a beta feature.

For example, I have a bunch of tests for the different paths middleware might take, and in the test file I have to just ignore that rule, yet in our modules, we respect the rule... it turns into a slight cognitive load from time to time.

[trm217]

@leerob According to the docs the middleware will not have access to the crypto package.
The first thing I thought about doing, when I heard middleware was coming, was to create a utility to conditionally rewrite URLS to different statically generated pages based on the users authorization state.
I then implemented this with Next.js 12.1.5 by validating a JWT token with a public key in the middleware and then rewrite the url based on the scopes in the token-payload. Now without the crypto package, this isn't possible anymore.
Any chance that crypto could be made available using a polyfill?

[icyJoseph]

We use jose to do crypto stuff in our middleware, https://www.npmjs.com/package/jose, works very well!

[trm217]

Thanks for your hint, I will look into it! 🙇🏻

[patrick-mcdougle]

Anyone know why console.trace was not bound here?

[icyJoseph]

Well according to the list of support logging functions, https://nextjs.org/docs/api-reference/edge-runtime#logging, not even error should be supported. We had to move away from Pino logger, and just wrote a thin stringifier for DataDog, which is working very well (it's like 5 lines of code).

[patrick-mcdougle]

Also, does anyone know if there's a way to access the ORIGINAL req from a middleware?

When I'm using Vercel, the locale detection middleware is kicking in before mine, and I can't access the url as requested by the user, it has already be re-written. This makes it impossible to detect if you're about to create an infinite redirect since you don't know what the original url was.

[bb-in-hoodie]

Would there be Node.js APIs support any time soon?

I wanted to store every single access log to ElasticSearch (including HTTP API request, static files, pages whatever). Then I found this middleware API and I sounds like a thing I was looking for. But in a couple of hours I felt disappointed because I just figured out it doesn't support a very popular logging library, winston.

"You may find another library!" won't help it. Because in our company, we do manage kind of a logging platform called 'NELO' (which is basically a wrapper of ES) on our own and that NELO team offers a SDK which is also kind of a wrapper of, of course, winston.

Maybe it's just me but when I first heard about 'Middleware API' it felt so much like a server-side stuff. And the fact that server-side feature doesn't support Node.js APIs sound a bit ironic to me.

[icyJoseph]

I wanted to store every single access log to ElasticSearch (including HTTP API request, static files, pages whatever). Then I found this middleware API and I sounds like a thing I was looking for. But in a couple of hours I felt disappointed because I just figured out it doesn't support a very popular logging library, winston.

That was wrong of you. There's a list of supported APIs. This environment is not Node.js, but a simplified V8 engine, that's made to run code very fast, and without need for cold starts.

Some libraries use code that's not really portable. Node.js is not the only JS environment, and the latest tech trend, on which the edge runtime sits, is all about universal JavaScript that runs anywhere.

For instance, this edge runtime has some crypto support, but not the entire set of crypto algorithms, for that, in a project where I work, we use jose, which uses the basic set of crypto support and builds upon it.

Recently, in 12.1.6 our logging library was also impacted, Pino. It used a dependency that does eval or new Function, and thus, we had to drop it, and write our own thin DataDog serialiser.

What I am trying to get to here, is that we are in a sort of transitional period into the edge, and we ought to wait for the ecosystem to be mature. It's not just Vercel, there's also Cloudflare Workers, Deno has its own, etc., do not get frustrated because a feature on Beta stage is giving you issues. Wait a bit, and there'll be more options.

[bb-in-hoodie]

The important thing is

• there are a number of people who won't use edge...stuff (just simply run the things on their next.js server as usual)
• and we don't have any alternative which might work like 'a middleware' instead of this Middleware API.

We, as users, need something that catches all the requests and process something with it before responds to it. And that exact thing is 'middleware'. Yes, of course many people would be happy to make it run on edge server. But majority of users simply want a thing that just works as express-like middleware.

Even MIddleware document says,

This gives you full flexibility in Next.js, because you can run code before a request is completed.

That's the key point of middleware feature, not 'it is running on edge servers'. If edge runtime thing is important, of course it would be nice if it can 'also' support edge runtime. But forcing all the middlewares to be fit into edge runtime doesn't sound reasonable to me.

It reminds me of Half-life: Alyx. What we wanted was a sequel of Half-life series, but what they gave us was a VR game with flavor of Half-life. The game was sweet, but majority of gamers couldn't even experience it.

[icyJoseph]

I guess this is a matter of communication. If I had to load an entire library, as cold start, every time a request arrives at my server, it'd make up for a very slow application. Middleware ought to be lightweight and simple.

And this is where looking at the totality of things comes into place. This is a feature in beta stage, and there's documentation which clearly shows what's possible and not.

What's more, the problem here is that a library at use, is not working, while the entire Edge runtime has a rich API that anyone can build upon. There's nothing blocking developers from the "logging" end goal.

I'd say that analogies in this case are not to be taken lightly, and again, we have to look at the entire feature and the communication.

Edit

For what is worth, I tried to make Winston work with the Edge, but the package just depends on a lot of Node.js APIs, fs, util, os, tty, events, buffer, zlib, path, http, https, either directly or through dependencies.

Sorry, I thought I could make it work, but it's just not made for anything else but Node.js -

[bb-in-hoodie]

I get it, thanks for your reply.

I understand Middleware concept originally came out from Next.js' journey of supporting edge servers. But I just want you to know there must be a lot of people who simply needs a middleware feature, putting Edge concept aside.

For such users, 'middleware should be light as possible' can no longer be an excuse of dropping node.js API support. Because what we want is just a middleware feature as it is, not a middleware that works on an edge server.

---

By the way, I didn't expect you to spend your time testing on winston for me. That's sweet, thanks a lot :D

[GabenGar]

NextJS can always be built as a bunch of static pages with the client script on top, so you can slap whatever backend with its own middleware to it. Otherwise it is made for serverless environments to abstract the complexity of making server-rendered pages.
The only way node-specific packages can work with it if their authors rewrite them in ESM. But that's not going to happen any time soon because it's not only a lot of work, it's also a non-trivial work especially for node-only packages.

[ofhouse]

Seems like the recent PRs (#36772 & #36835) reverse some points that were part of the original RFC:

• Support for nested middleware is removed
• Response body creation / modification from middleware is no longer possible

Could the RFC be updated to reflect the current state of the API design, please?

cc @leerob

[leerob]

Will absolutely be swinging back with an update 😄

#29750 (comment)

[khuezy]

@leerob Hi, what was the reasoning on removing support for nested middleware? There's a good use case for nested middleware like middleware chaining for certain paths and modular middleware logic.

[leerob]

Hey everyone! Appreciate all of the feedback here on this RFC as folks have been using Middleware while it's in beta. We're reviewing your feedback and will be incorporating it into the next version of Middleware. I'll share more on this soon with details on how to upgrade and the changes we're making to better support y'all. Thank you!

[leerob]

Here's the upgrade guide, which should be merged very soon: #37382

[leerob]

Merged! https://nextjs.org/docs/messages/middleware-upgrade-guide

[threehams]

The docs don't mention one thing about edge functions: if you're using getInitialProps, and prefetch isn't an option (form submission, for instance), there's an extra round-trip from looking up the rewritten URL before getInitialProps runs.

getServerSideProps drops that down to a single round-trip, but #19611 explains why there are downsides to that.

[bennettdams]

Using middleware for on-demand revalidation/ISR

The following was already asked in this discussion, adding it here for visibility.

Describe the feature you'd like to request

I'm using middlewares to protect sites from unauthenticated access. Unfortunately the new on-demand revalidation and its requests are also intercepted by the middleware.

In my case, unauthenticated users are redirected to the sign in page. Here's part of the middleware for reference:

// _middleware.ts (in root)
...
    if (isSignedIn) {
      // user is signed in, go on
      return NextResponse.next();
    } else {
      const urlNew = req.nextUrl.clone();
      urlNew.pathname = ROUTES.SIGN_IN;

      return NextResponse.redirect(urlNew);
    }

I obviously don't want to do this redirection for the revalidation requests.

Right now, I circumvent this by looking at the header of the middleware request:

const isRevalidationRequest = !!req.headers.get("x-prerender-revalidate");

Requests coming from on-demand revalidation (await res.unstable_revalidate("/some-path")) will have this header. I can skip the redirection for such requests, but this is obviously not great.

Is there a better way?

Describe the solution you'd like

Possible solutions I thought about:

• Middlewares can detect revalidation requests automatically and can be configured by us to ignore them/pass them through as-is
• Requests of revalidation executions can be modified, so we can e.g. add a request body that contains a secret:

  const mySecret = { ... }
  // `mySecret` will be added as request body
  await res.unstable_revalidate("/some-path", mySecret);

[leerob]

In preparation for Middleware stability, we just merged an upgrade guide with the latest API changes. You can try out these changes on the latest canary release today. We'd love to hear your feedback. Thank you!

npm i -g next@canary

[leerob]

What use cases were you looking for?

[bryanrsmith]

@leerob Is it possible to run middleware only on initial requests to pages and not on client-side navigations? This seems to be something a lot of people struggle with, myself included. (#29750 (comment), #29750 (comment), https://twitter.com/samselikoff/status/1513956911535861766)

Use case: My site has content that's customized for geographic region. When a user lands on the site I want to redirect them to the appropriate region path based on request.geo. After that initial page load I'd like to skip the prefetch requests that happen on client-side navigations because the user is already in the right region path. The best option I've found is to look for the x-middleware-preflight header in the middleware, but I'd rather avoid the preflight and middleware execution entirely after that first page load.

[bryanrsmith]

What use cases were you looking for?

Returning geoip information to the client is pretty useful, as in Vercel's demo page for this feature: https://vercel.com/features/edge-functions

[liamross]

What use cases were you looking for?

Any use case where the response could be generated on the edge to minimize round trip time. One example could be to do dynamic generation of a blocking script based on some parameters or values stored in global redis like upstash, edge reduces the round trip time and thus blocking time.

I understand this maybe isn't the intended use for middleware in NextJS, and obviously I could use another edge service like CloudFlare etc, but I'm just curious why the restriction was added that prevents this kind of thing altogether.

[liamross]

Ah my concerns were answered by the experimental edge API routes, thanks @leerob

[luizgribeiro]

Hey there!
I'm having a hard time trying to use canary middleware's for Routing based on Auth token header and thoght that it could be valuable on this RFC. I have also created this POC in which different branches show the issues that I'm facing. Here comes the description:

Use case & structure:

I'd like to use a middleware to redirect users to /login if they lack an specific header/token or their token has expired.
The index page is the one that should only be accessible if the token is present and valid. Otherwise, /login page should be used.

Problems & Branches:

Too Many Requests

The middleware code bellow (quite similar to examples) results in redirect loops that are canceled by the browser, since no token is ever set on redirect to the /login page.

export function middleware(req: NextRequest) {
  const token = getAuthToken(req.cookies);

  console.log(
    `hasToken: ${token ? true : false} | pathName: ${req.nextUrl.pathname}`
  );

  if (token) {
    return NextResponse.next();
  } else {
    console.log("REDIRECT");
    const loginUrl = new URL("/login", req.url);
    loginUrl.searchParams.set("from", req.nextUrl.pathname);
    return NextResponse.redirect(loginUrl);
  }
}

Browser response:

_next Path Redirects

I decided to add a condition to allow any access to /login page to be done as follows:

if (token || req.nextUrl.pathname.match(/login/)) {
    return NextResponse.next();
  }

But that led to issues on requests for /next (as informed on the migration guide it is now processed by middleware as well). Here's a print showing that any access to that path resulted on a redirect to /login.

Browser Result: "Blank page"

Enable Access to _next

After that I decided to allow access to all routes that had _next on it. As the print bellow shows, there's no redirect occurring on /login or _next. Anyway, the final result of the redirect was still a blank page.

Am I correct on this approach and assumptions?
What am I missing out?

[leerob]

The Middleware API is now stable with Next.js 12.2 🎉

Learn more about the release or view the upgrade guide.

[jordie23]

Are we able to use runtime environment variables in middleware yet?

Edit: Went ahead and ran a test. It does indeed look like runtime variables work in middleware now which is awesome! We can make very good use of this feature now. thank you!

[trihoang1011]

I have problem on using middleware with standalone build.
It worked fine on my local, but not on production standalone build
I found this error on k8s log
Error: Cannot find module 'next/dist/compiled/@edge-runtime/primitives/console'

my NextJS version is 12.2.3
any advice?