fix: block image optimization during middleware requests

[RobPruzan]

This PR updates the middleware not applied to _next/image fix to stay consistent with handleNextDataRequest, and avoid any unexpected behavior

Explanation of changes

The previous breaking change was at https://github.com/vercel/next.js/pull/57161/files#diff-6f4291cc2bfc5073fdca12a014011769e840ee68583db1468acef075f037015aL1245

Where a call to:
await this.handleNextDataRequest(req, res, parsedUrl)

Was refactored to

await this.handle(req, res, parsedUrl)

Where handle was defined as

  protected handle: RouteHandler = async (req, res, url) => {
    let finished = await this.handleNextImageRequest(req, res, url)
    if (finished) return true

    finished = await this.handleNextDataRequest(req, res, url)
    if (finished) return true

    if (this.minimalMode && this.hasAppDir) {
      finished = await this.handleRSCRequest(req, res, url)
      if (finished) return true
    }
  }

handleNextImageRequest (the function that optimizes images) gets called in an instance it wasn’t before.

The reason its valid to call handleNextDataRequest in that path is because there’s a middleware check early returns:
https://github.com/vercel/next.js/blob/224447cd65d23f2dec2119b0c9ef10b79532dc6e/packages/next/src/server/base-server.ts#L698-L703

While handleNextImageRequest does not.

The suggested fix in the PR kinda fixes the problem, but a key thing to note is that currently handleNextImageRequest returns true in every happy path case (and the case it currently returns false seems like it should be an enforced invariant). And in previous commits every code path did return true (not including exceptions)

But this may break other callers that expect the handleNextImageRequest to succeed. I haven’t tested this/ ran through the hypothetical broken code path, but I suspect a well thought out test could catch it. Quick scan over all the calls of handleNextImageRequest would set of alarm bells if you assume it always returns false now.

So a reasonable solution would be to stay consistent and early return if the request is for middleware within handleNextImageRequest. The only unknown is if we should also block on edge? But I’m going to assume not since there was never an edge check for image optimization- to hedge I don’t have any knowledge on what can run on edge in this context.

And for satisfaction/understanding, the new handleNextImageRequest (added here https://github.com/vercel/next.js/pull/57161/files#diff-6f4291cc2bfc5073fdca12a014011769e840ee68583db1468acef075f037015aL1245) was redundant, you can confirm the image optimization happens in the useInvokePath branch.

https://github.com/vercel/next.js/blob/224447cd65d23f2dec2119b0c9ef10b79532dc6e/packages/next/src/server/base-server.ts#L1406-L1464

if (useInvokePath) {
   …	
   await this.handleNextImageRequest(req, res, url)
}

And it in the end, it probably does make sense to move image optimization out of the middleware path, which the suggested changes would accomplish.

[ecline123]

What is blocking this?