Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Middleware can't detect image requests #37939

Closed
1 task done
11koukou opened this issue Jun 23, 2022 · 4 comments
Closed
1 task done

Middleware can't detect image requests #37939

11koukou opened this issue Jun 23, 2022 · 4 comments
Labels
bug Issue was opened via the bug report template. Middleware Related to Next.js Middleware

Comments

@11koukou
Copy link
Contributor

Verify canary release

  • I verified that the issue exists in the latest Next.js canary release

Provide environment information

Operating System:
Platform: win32
Arch: x64
Version: Windows 10 Enterprise LTSC 2019
Binaries:
Node: 16.7.0
npm: N/A
Yarn: N/A
pnpm: N/A
Relevant packages:
next: 12.1.7-canary.45
react: 17.0.2
react-dom: 17.0.2

What browser are you using? (if relevant)

Firefox 101.0.1

How are you deploying your application? (if relevant)

No response

Describe the Bug

Hello after upgrading to latest canary release and changing from _middleware.ts to middleware.ts, every request for an image inside my public folder has the "/_next/image" pathname reported inside middleware, while it used to be e.g. "/myImage.png". So it breaks the https://nextjs.org/docs/advanced-features/i18n-routing#prefixing-the-default-locale functionality as it can not correctly detect images anymore. My middleware content is exactly the same as the one in the documentation, nothing added/removed or changed.

Expected Behavior

Either the documentation about prefixing the default locale, or the middleware implementation need to change for correctly detecting images and not affecting their url.

Link to reproduction

https://nextjs.org/docs/advanced-features/i18n-routing#prefixing-the-default-locale

To Reproduce

Just follow the https://nextjs.org/docs/advanced-features/i18n-routing#prefixing-the-default-locale guideline

@11koukou 11koukou added the bug Issue was opened via the bug report template. label Jun 23, 2022
@balazsorban44 balazsorban44 added the Middleware Related to Next.js Middleware label Jun 23, 2022
@ksocha
Copy link

ksocha commented Jul 5, 2022

I can confirm this, encountered the same issue when was trying to upgrade from 12.1.0 to 12.2.0.

Edit:
Was able to fix my case by modifying following statement a bit:

  const shouldHandleLocale =
    !PUBLIC_FILE.test(request.nextUrl.pathname) &&
    !request.nextUrl.pathname.includes('/api/') &&
    request.nextUrl.locale === 'default'

becomes

  const shouldHandleLocale =
    !PUBLIC_FILE.test(request.nextUrl.pathname) &&
    !request.nextUrl.pathname.includes('/api/') &&
    !request.nextUrl.pathname.includes('/_next/') &&
    request.nextUrl.locale === 'default'

@11koukou
Copy link
Contributor Author

11koukou commented Jul 5, 2022

Yes that's the way for now. However the documentation will need to be changed to reflect this change. Personally I have paused using the new middleware until the even more serious issues (e.g. #38267) get fixed.

@11koukou
Copy link
Contributor Author

11koukou commented Jul 8, 2022

Latest documentation change about prefixing states clearly what to do so I will close this issue, thanks.

@11koukou 11koukou closed this as completed Jul 8, 2022
@github-actions
Copy link
Contributor

github-actions bot commented Aug 7, 2022

This closed issue has been automatically locked because it had no new activity for a month. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Aug 7, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Issue was opened via the bug report template. Middleware Related to Next.js Middleware
Projects
None yet
Development

No branches or pull requests

3 participants