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.

Sign up for GitHub

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

Jump to bottom

fix i18n data pathname resolving #68947

Merged
merged 2 commits into from
Aug 15, 2024
Merged

fix i18n data pathname resolving #68947

merged 2 commits into from
Aug 15, 2024

Conversation

ztanner
Copy link
Member

@ztanner ztanner commented Aug 15, 2024 •
edited
Loading

What

When using middleware + i18n in pages router, and upon navigation to a dynamic route, the wrong locale would be served in getServerSideProps.

Why

The route resolver code handles detecting the initial locale by splitting the path and looking at the first non-empty index to determine which locale was set. However, it does this assuming it has a regular path name, and not a /_next/data URL.

When middleware is present, the route resolver code hits the middleware_next_data branch, which doesn't have any logic to properly set the locale. This means that resolveRoutes will return the default locale rather than the locale from the path.

In the non-middleware case, this would normally flow through handleNextDataRequest in base-server which has handling to infer i18n via i18nProvider. This branch is functionally very similar to what we're doing in resolveRoutes but it does so in a different way: it reconstructs the URL without the /_next/data information and then attaches locale information. However because middleware_next_data rewrites the pathname to the actual route (ie /_next/data/development/foo.json -> /foo), handleNextDataRequest won't handle that request since it's no longer a data request.

It's strange to me that handleNextDataRequest and middleware_next_data are doing similar path normalization in completely different ways, but that was a deeper rabbit hole and simply removing the normalization logic in resolveRoutes causes other problems.

How

Since data requests that flow through this middleware matcher logic aren't going to be handled by handleNextDataRequest, I've updated middleware_next_data to perform the logic of attaching the locale information to the query. Initially I was going to do this for anything that calls normalizeLocalePath but it seems like other branches of resolveRoutes do it in the matcher function directly.

Fixes #54217
Closes NDX-116

@ztanner Graphite App
Copy link
Member Author

ztanner commented Aug 15, 2024

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @ztanner and the rest of your teammates on Graphite Graphite

@ijjk
Copy link
Member

ijjk commented Aug 15, 2024 •
edited
Loading

Tests Passed

@ijjk
Copy link
Member

ijjk commented Aug 15, 2024 •
edited
Loading

Stats from current PR

Default Build (Increase detected ⚠️)
General Overall increase ⚠️
vercel/next.js canary vercel/next.js 08-15-fix_i18n_data_pathname_resolving Change
buildDuration 18.3s 15.7s N/A
buildDurationCached 8.6s 7.4s N/A
nodeModulesSize 356 MB 356 MB ⚠️ +3.69 kB
nextStartRea..uration (ms) 426ms 426ms ✓
Client Bundles (main, webpack)
vercel/next.js canary vercel/next.js 08-15-fix_i18n_data_pathname_resolving Change
4958.HASH.js gzip 169 B 168 B N/A
6405-HASH.js gzip 5.19 kB 5.19 kB N/A
8711-HASH.js gzip 37.9 kB 37.9 kB N/A
d09468e9-HASH.js gzip 51.9 kB 51.9 kB N/A
framework-HASH.js gzip 56.8 kB 56.7 kB N/A
main-app-HASH.js gzip 223 B 225 B N/A
main-HASH.js gzip 32.5 kB 32.5 kB N/A
webpack-HASH.js gzip 1.71 kB 1.71 kB N/A
Overall change 0 B 0 B ✓
Legacy Client Bundles (polyfills)
vercel/next.js canary vercel/next.js 08-15-fix_i18n_data_pathname_resolving Change
polyfills-HASH.js gzip 31 kB 31 kB ✓
Overall change 31 kB 31 kB ✓
Client Pages
vercel/next.js canary vercel/next.js 08-15-fix_i18n_data_pathname_resolving Change
_app-HASH.js gzip 194 B 192 B N/A
_error-HASH.js gzip 191 B 192 B N/A
amp-HASH.js gzip 512 B 511 B N/A
css-HASH.js gzip 342 B 344 B N/A
dynamic-HASH.js gzip 1.84 kB 1.84 kB N/A
edge-ssr-HASH.js gzip 265 B 266 B N/A
head-HASH.js gzip 361 B 364 B N/A
hooks-HASH.js gzip 390 B 393 B N/A
image-HASH.js gzip 4.4 kB 4.4 kB N/A
index-HASH.js gzip 268 B 267 B N/A
link-HASH.js gzip 2.82 kB 2.81 kB N/A
routerDirect..HASH.js gzip 328 B 328 B ✓
script-HASH.js gzip 397 B 397 B ✓
withRouter-HASH.js gzip 324 B 324 B ✓
1afbb74e6ecf..834.css gzip 106 B 106 B ✓
Overall change 1.16 kB 1.16 kB ✓
Client Build Manifests
vercel/next.js canary vercel/next.js 08-15-fix_i18n_data_pathname_resolving Change
_buildManifest.js gzip 747 B 749 B N/A
Overall change 0 B 0 B ✓
Rendered Page Sizes
vercel/next.js canary vercel/next.js 08-15-fix_i18n_data_pathname_resolving Change
index.html gzip 525 B 521 B N/A
link.html gzip 539 B 538 B N/A
withRouter.html gzip 521 B 520 B N/A
Overall change 0 B 0 B ✓
Edge SSR bundle Size
vercel/next.js canary vercel/next.js 08-15-fix_i18n_data_pathname_resolving Change
edge-ssr.js gzip 127 kB 127 kB N/A
page.js gzip 173 kB 173 kB N/A
Overall change 0 B 0 B ✓
Middleware size
vercel/next.js canary vercel/next.js 08-15-fix_i18n_data_pathname_resolving Change
middleware-b..fest.js gzip 672 B 668 B N/A
middleware-r..fest.js gzip 156 B 156 B ✓
middleware.js gzip 29.6 kB 29.6 kB ✓
edge-runtime..pack.js gzip 844 B 844 B ✓
Overall change 30.6 kB 30.6 kB ✓
Next Runtimes
vercel/next.js canary vercel/next.js 08-15-fix_i18n_data_pathname_resolving Change
928-experime...dev.js gzip 322 B 322 B ✓
928.runtime.dev.js gzip 314 B 314 B ✓
app-page-exp...dev.js gzip 307 kB 307 kB ✓
app-page-exp..prod.js gzip 121 kB 121 kB ✓
app-page-tur..prod.js gzip 133 kB 133 kB ✓
app-page-tur..prod.js gzip 129 kB 129 kB ✓
app-page.run...dev.js gzip 297 kB 297 kB ✓
app-page.run..prod.js gzip 117 kB 117 kB ✓
app-route-ex...dev.js gzip 30.7 kB 30.7 kB ✓
app-route-ex..prod.js gzip 20.7 kB 20.7 kB ✓
app-route-tu..prod.js gzip 20.7 kB 20.7 kB ✓
app-route-tu..prod.js gzip 20.5 kB 20.5 kB ✓
app-route.ru...dev.js gzip 32.3 kB 32.3 kB ✓
app-route.ru..prod.js gzip 20.5 kB 20.5 kB ✓
pages-api-tu..prod.js gzip 9.59 kB 9.59 kB ✓
pages-api.ru...dev.js gzip 11.4 kB 11.4 kB ✓
pages-api.ru..prod.js gzip 9.58 kB 9.58 kB ✓
pages-turbo...prod.js gzip 21.6 kB 21.6 kB ✓
pages.runtim...dev.js gzip 27.5 kB 27.5 kB ✓
pages.runtim..prod.js gzip 21.6 kB 21.6 kB ✓
server.runti..prod.js gzip 56.7 kB 56.7 kB ✓
Overall change 1.41 MB 1.41 MB ✓
build cache Overall increase ⚠️
vercel/next.js canary vercel/next.js 08-15-fix_i18n_data_pathname_resolving Change
0.pack gzip 1.49 MB 1.49 MB ⚠️ +1.3 kB
index.pack gzip 127 kB 127 kB ⚠️ +340 B
Overall change 1.62 MB 1.62 MB ⚠️ +1.64 kB
Diff details
Diff for page.js 
@@ -15,7 +15,7 @@
       /***/
     },
 
-    /***/ 1398: /***/ (
+    /***/ 73: /***/ (
       __unused_webpack_module,
       __webpack_exports__,
       __webpack_require__
@@ -30,7 +30,7 @@
         default: () => /* binding */ nHandler,
       });
 
-      // NAMESPACE OBJECT: ./node_modules/.pnpm/next@file+..+main-repo+packages+next+next-packed.tgz_react-dom@19.0.0-rc-187dd6a7-20240806_re_6tugpsz4gl2xsqrwds5bwcbi3y/node_modules/next/dist/build/webpack/loaders/next-app-loader.js?name=app%2Fapp-edge-ssr%2Fpage&page=%2Fapp-edge-ssr%2Fpage&pagePath=private-next-app-dir%2Fapp-edge-ssr%2Fpage.js&appDir=%2Ftmp%2Fnext-statsmzJ4NS%2Fstats-app%2Fapp&appPaths=%2Fapp-edge-ssr%2Fpage&pageExtensions=tsx&pageExtensions=ts&pageExtensions=jsx&pageExtensions=js&basePath=&assetPrefix=&nextConfigOutput=&flyingShuttle=false&preferredRegion=&middlewareConfig=e30%3D!./app/app-edge-ssr/page.js?__next_edge_ssr_entry__
+      // NAMESPACE OBJECT: ./node_modules/.pnpm/next@file+..+diff-repo+packages+next+next-packed.tgz_react-dom@19.0.0-rc-187dd6a7-20240806_re_wxf3je55uhqnotjiz3wkaonabu/node_modules/next/dist/build/webpack/loaders/next-app-loader.js?name=app%2Fapp-edge-ssr%2Fpage&page=%2Fapp-edge-ssr%2Fpage&pagePath=private-next-app-dir%2Fapp-edge-ssr%2Fpage.js&appDir=%2Ftmp%2Fnext-statsmzJ4NS%2Fstats-app%2Fapp&appPaths=%2Fapp-edge-ssr%2Fpage&pageExtensions=tsx&pageExtensions=ts&pageExtensions=jsx&pageExtensions=js&basePath=&assetPrefix=&nextConfigOutput=&flyingShuttle=false&preferredRegion=&middlewareConfig=e30%3D!./app/app-edge-ssr/page.js?__next_edge_ssr_entry__
       var page_next_edge_ssr_entry_namespaceObject = {};
       __webpack_require__.r(page_next_edge_ssr_entry_namespaceObject);
       __webpack_require__.d(page_next_edge_ssr_entry_namespaceObject, {
@@ -66,35 +66,35 @@
         tree: () => tree,
       });
 
-      // EXTERNAL MODULE: ./node_modules/.pnpm/next@file+..+main-repo+packages+next+next-packed.tgz_react-dom@19.0.0-rc-187dd6a7-20240806_re_6tugpsz4gl2xsqrwds5bwcbi3y/node_modules/next/dist/esm/server/web/globals.js
-      var globals = __webpack_require__(1921);
-      // EXTERNAL MODULE: ./node_modules/.pnpm/next@file+..+main-repo+packages+next+next-packed.tgz_react-dom@19.0.0-rc-187dd6a7-20240806_re_6tugpsz4gl2xsqrwds5bwcbi3y/node_modules/next/dist/esm/server/web/adapter.js + 3 modules
-      var adapter = __webpack_require__(8139);
-      // EXTERNAL MODULE: ./node_modules/.pnpm/next@file+..+main-repo+packages+next+next-packed.tgz_react-dom@19.0.0-rc-187dd6a7-20240806_re_6tugpsz4gl2xsqrwds5bwcbi3y/node_modules/next/dist/esm/build/webpack/loaders/next-edge-ssr-loader/render.js + 86 modules
-      var render = __webpack_require__(7088);
-      // EXTERNAL MODULE: ./node_modules/.pnpm/next@file+..+main-repo+packages+next+next-packed.tgz_react-dom@19.0.0-rc-187dd6a7-20240806_re_6tugpsz4gl2xsqrwds5bwcbi3y/node_modules/next/dist/esm/server/lib/incremental-cache/index.js + 3 modules
-      var incremental_cache = __webpack_require__(5737);
-      // EXTERNAL MODULE: ./node_modules/.pnpm/next@file+..+main-repo+packages+next+next-packed.tgz_react-dom@19.0.0-rc-187dd6a7-20240806_re_6tugpsz4gl2xsqrwds5bwcbi3y/node_modules/next/dist/esm/server/app-render/app-render.js + 71 modules
-      var app_render = __webpack_require__(4225);
-      // EXTERNAL MODULE: ./node_modules/.pnpm/next@file+..+main-repo+packages+next+next-packed.tgz_react-dom@19.0.0-rc-187dd6a7-20240806_re_6tugpsz4gl2xsqrwds5bwcbi3y/node_modules/next/dist/esm/server/route-modules/app-page/module.compiled.js
-      var module_compiled = __webpack_require__(7377);
-      // EXTERNAL MODULE: ./node_modules/.pnpm/next@file+..+main-repo+packages+next+next-packed.tgz_react-dom@19.0.0-rc-187dd6a7-20240806_re_6tugpsz4gl2xsqrwds5bwcbi3y/node_modules/next/dist/esm/server/route-kind.js
-      var route_kind = __webpack_require__(4651);
-      // EXTERNAL MODULE: ./node_modules/.pnpm/next@file+..+main-repo+packages+next+next-packed.tgz_react-dom@19.0.0-rc-187dd6a7-20240806_re_6tugpsz4gl2xsqrwds5bwcbi3y/node_modules/next/dist/esm/client/components/error-boundary.js
-      var error_boundary = __webpack_require__(8775);
-      // EXTERNAL MODULE: ./node_modules/.pnpm/next@file+..+main-repo+packages+next+next-packed.tgz_react-dom@19.0.0-rc-187dd6a7-20240806_re_6tugpsz4gl2xsqrwds5bwcbi3y/node_modules/next/dist/esm/server/app-render/entry-base.js + 8 modules
-      var entry_base = __webpack_require__(5864); // CONCATENATED MODULE: ./node_modules/.pnpm/next@file+..+main-repo+packages+next+next-packed.tgz_react-dom@19.0.0-rc-187dd6a7-20240806_re_6tugpsz4gl2xsqrwds5bwcbi3y/node_modules/next/dist/build/webpack/loaders/next-app-loader.js?name=app%2Fapp-edge-ssr%2Fpage&page=%2Fapp-edge-ssr%2Fpage&pagePath=private-next-app-dir%2Fapp-edge-ssr%2Fpage.js&appDir=%2Ftmp%2Fnext-statsmzJ4NS%2Fstats-app%2Fapp&appPaths=%2Fapp-edge-ssr%2Fpage&pageExtensions=tsx&pageExtensions=ts&pageExtensions=jsx&pageExtensions=js&basePath=&assetPrefix=&nextConfigOutput=&flyingShuttle=false&preferredRegion=&middlewareConfig=e30%3D!./app/app-edge-ssr/page.js?__next_edge_ssr_entry__
+      // EXTERNAL MODULE: ./node_modules/.pnpm/next@file+..+diff-repo+packages+next+next-packed.tgz_react-dom@19.0.0-rc-187dd6a7-20240806_re_wxf3je55uhqnotjiz3wkaonabu/node_modules/next/dist/esm/server/web/globals.js
+      var globals = __webpack_require__(8037);
+      // EXTERNAL MODULE: ./node_modules/.pnpm/next@file+..+diff-repo+packages+next+next-packed.tgz_react-dom@19.0.0-rc-187dd6a7-20240806_re_wxf3je55uhqnotjiz3wkaonabu/node_modules/next/dist/esm/server/web/adapter.js + 3 modules
+      var adapter = __webpack_require__(3869);
+      // EXTERNAL MODULE: ./node_modules/.pnpm/next@file+..+diff-repo+packages+next+next-packed.tgz_react-dom@19.0.0-rc-187dd6a7-20240806_re_wxf3je55uhqnotjiz3wkaonabu/node_modules/next/dist/esm/build/webpack/loaders/next-edge-ssr-loader/render.js + 86 modules
+      var render = __webpack_require__(4271);
+      // EXTERNAL MODULE: ./node_modules/.pnpm/next@file+..+diff-repo+packages+next+next-packed.tgz_react-dom@19.0.0-rc-187dd6a7-20240806_re_wxf3je55uhqnotjiz3wkaonabu/node_modules/next/dist/esm/server/lib/incremental-cache/index.js + 3 modules
+      var incremental_cache = __webpack_require__(2989);
+      // EXTERNAL MODULE: ./node_modules/.pnpm/next@file+..+diff-repo+packages+next+next-packed.tgz_react-dom@19.0.0-rc-187dd6a7-20240806_re_wxf3je55uhqnotjiz3wkaonabu/node_modules/next/dist/esm/server/app-render/app-render.js + 71 modules
+      var app_render = __webpack_require__(6146);
+      // EXTERNAL MODULE: ./node_modules/.pnpm/next@file+..+diff-repo+packages+next+next-packed.tgz_react-dom@19.0.0-rc-187dd6a7-20240806_re_wxf3je55uhqnotjiz3wkaonabu/node_modules/next/dist/esm/server/route-modules/app-page/module.compiled.js
+      var module_compiled = __webpack_require__(1077);
+      // EXTERNAL MODULE: ./node_modules/.pnpm/next@file+..+diff-repo+packages+next+next-packed.tgz_react-dom@19.0.0-rc-187dd6a7-20240806_re_wxf3je55uhqnotjiz3wkaonabu/node_modules/next/dist/esm/server/route-kind.js
+      var route_kind = __webpack_require__(3939);
+      // EXTERNAL MODULE: ./node_modules/.pnpm/next@file+..+diff-repo+packages+next+next-packed.tgz_react-dom@19.0.0-rc-187dd6a7-20240806_re_wxf3je55uhqnotjiz3wkaonabu/node_modules/next/dist/esm/client/components/error-boundary.js
+      var error_boundary = __webpack_require__(674);
+      // EXTERNAL MODULE: ./node_modules/.pnpm/next@file+..+diff-repo+packages+next+next-packed.tgz_react-dom@19.0.0-rc-187dd6a7-20240806_re_wxf3je55uhqnotjiz3wkaonabu/node_modules/next/dist/esm/server/app-render/entry-base.js + 8 modules
+      var entry_base = __webpack_require__(8188); // CONCATENATED MODULE: ./node_modules/.pnpm/next@file+..+diff-repo+packages+next+next-packed.tgz_react-dom@19.0.0-rc-187dd6a7-20240806_re_wxf3je55uhqnotjiz3wkaonabu/node_modules/next/dist/build/webpack/loaders/next-app-loader.js?name=app%2Fapp-edge-ssr%2Fpage&page=%2Fapp-edge-ssr%2Fpage&pagePath=private-next-app-dir%2Fapp-edge-ssr%2Fpage.js&appDir=%2Ftmp%2Fnext-statsmzJ4NS%2Fstats-app%2Fapp&appPaths=%2Fapp-edge-ssr%2Fpage&pageExtensions=tsx&pageExtensions=ts&pageExtensions=jsx&pageExtensions=js&basePath=&assetPrefix=&nextConfigOutput=&flyingShuttle=false&preferredRegion=&middlewareConfig=e30%3D!./app/app-edge-ssr/page.js?__next_edge_ssr_entry__
       const component0 = () =>
         Promise.resolve(/* import() eager */).then(
-          __webpack_require__.bind(__webpack_require__, 3876)
+          __webpack_require__.bind(__webpack_require__, 5490)
         );
       const component1 = () =>
         Promise.resolve(/* import() eager */).then(
-          __webpack_require__.bind(__webpack_require__, 7715)
+          __webpack_require__.bind(__webpack_require__, 8383)
         );
       const page2 = () =>
         Promise.resolve(/* import() eager */).then(
-          __webpack_require__.bind(__webpack_require__, 7310)
+          __webpack_require__.bind(__webpack_require__, 3689)
         );
 
       // We inject the tree and pages here so that we can use them in the route
@@ -160,12 +160,12 @@
       });
 
       //# sourceMappingURL=app-page.js.map
-      // EXTERNAL MODULE: ./node_modules/.pnpm/next@file+..+main-repo+packages+next+next-packed.tgz_react-dom@19.0.0-rc-187dd6a7-20240806_re_6tugpsz4gl2xsqrwds5bwcbi3y/node_modules/next/dist/esm/lib/page-types.js
-      var page_types = __webpack_require__(9467);
-      // EXTERNAL MODULE: ./node_modules/.pnpm/next@file+..+main-repo+packages+next+next-packed.tgz_react-dom@19.0.0-rc-187dd6a7-20240806_re_6tugpsz4gl2xsqrwds5bwcbi3y/node_modules/next/dist/esm/server/app-render/encryption-utils.js
-      var encryption_utils = __webpack_require__(7850);
-      // EXTERNAL MODULE: ./node_modules/.pnpm/next@file+..+main-repo+packages+next+next-packed.tgz_react-dom@19.0.0-rc-187dd6a7-20240806_re_6tugpsz4gl2xsqrwds5bwcbi3y/node_modules/next/dist/esm/server/app-render/action-utils.js
-      var action_utils = __webpack_require__(6918); // CONCATENATED MODULE: ./node_modules/.pnpm/next@file+..+main-repo+packages+next+next-packed.tgz_react-dom@19.0.0-rc-187dd6a7-20240806_re_6tugpsz4gl2xsqrwds5bwcbi3y/node_modules/next/dist/build/webpack/loaders/next-edge-ssr-loader/index.js?{"absolute500Path":"","absoluteAppPath":"next/dist/pages/_app","absoluteDocumentPath":"next/dist/pages/_document","absoluteErrorPath":"next/dist/pages/_error","absolutePagePath":"private-next-app-dir/app-edge-ssr/page.js","dev":false,"isServerComponent":true,"page":"/app-edge-ssr/page","stringifiedConfig":"eyJlbnYiOnt9LCJlc2xpbnQiOnsiaWdub3JlRHVyaW5nQnVpbGRzIjpmYWxzZX0sInR5cGVzY3JpcHQiOnsiaWdub3JlQnVpbGRFcnJvcnMiOmZhbHNlLCJ0c2NvbmZpZ1BhdGgiOiJ0c2NvbmZpZy5qc29uIn0sImRpc3REaXIiOiIubmV4dCIsImNsZWFuRGlzdERpciI6dHJ1ZSwiYXNzZXRQcmVmaXgiOiIiLCJjYWNoZU1heE1lbW9yeVNpemUiOjUyNDI4ODAwLCJjb25maWdPcmlnaW4iOiJuZXh0LmNvbmZpZy5qcyIsInVzZUZpbGVTeXN0ZW1QdWJsaWNSb3V0ZXMiOnRydWUsImdlbmVyYXRlRXRhZ3MiOnRydWUsInBhZ2VFeHRlbnNpb25zIjpbInRzeCIsInRzIiwianN4IiwianMiXSwicG93ZXJlZEJ5SGVhZGVyIjp0cnVlLCJjb21wcmVzcyI6dHJ1ZSwiaW1hZ2VzIjp7ImRldmljZVNpemVzIjpbNjQwLDc1MCw4MjgsMTA4MCwxMjAwLDE5MjAsMjA0OCwzODQwXSwiaW1hZ2VTaXplcyI6WzE2LDMyLDQ4LDY0LDk2LDEyOCwyNTYsMzg0XSwicGF0aCI6Ii9fbmV4dC9pbWFnZSIsImxvYWRlciI6ImRlZmF1bHQiLCJsb2FkZXJGaWxlIjoiIiwiZG9tYWlucyI6W10sImRpc2FibGVTdGF0aWNJbWFnZXMiOmZhbHNlLCJtaW5pbXVtQ2FjaGVUVEwiOjYwLCJmb3JtYXRzIjpbImltYWdlL3dlYnAiXSwiZGFuZ2Vyb3VzbHlBbGxvd1NWRyI6ZmFsc2UsImNvbnRlbnRTZWN1cml0eVBvbGljeSI6InNjcmlwdC1zcmMgJ25vbmUnOyBmcmFtZS1zcmMgJ25vbmUnOyBzYW5kYm94OyIsImNvbnRlbnREaXNwb3NpdGlvblR5cGUiOiJhdHRhY2htZW50IiwicmVtb3RlUGF0dGVybnMiOltdLCJ1bm9wdGltaXplZCI6ZmFsc2V9LCJkZXZJbmRpY2F0b3JzIjp7ImFwcElzclN0YXR1cyI6dHJ1ZSwiYnVpbGRBY3Rpdml0eSI6dHJ1ZSwiYnVpbGRBY3Rpdml0eVBvc2l0aW9uIjoiYm90dG9tLXJpZ2h0In0sIm9uRGVtYW5kRW50cmllcyI6eyJtYXhJbmFjdGl2ZUFnZSI6NjAwMDAsInBhZ2VzQnVmZmVyTGVuZ3RoIjo1fSwiYW1wIjp7ImNhbm9uaWNhbEJhc2UiOiIifSwiYmFzZVBhdGgiOiIiLCJzYXNzT3B0aW9ucyI6e30sInRyYWlsaW5nU2xhc2giOmZhbHNlLCJpMThuIjpudWxsLCJwcm9kdWN0aW9uQnJvd3NlclNvdXJjZU1hcHMiOmZhbHNlLCJvcHRpbWl6ZUZvbnRzIjp0cnVlLCJleGNsdWRlRGVmYXVsdE1vbWVudExvY2FsZXMiOnRydWUsInNlcnZlclJ1bnRpbWVDb25maWciOnt9LCJwdWJsaWNSdW50aW1lQ29uZmlnIjp7fSwicmVhY3RQcm9kdWN0aW9uUHJvZmlsaW5nIjpmYWxzZSwicmVhY3RTdHJpY3RNb2RlIjpudWxsLCJyZWFjdE1heEhlYWRlcnNMZW5ndGgiOjYwMDAsImh0dHBBZ2VudE9wdGlvbnMiOnsia2VlcEFsaXZlIjp0cnVlfSwibG9nZ2luZyI6e30sInN0YXRpY1BhZ2VHZW5lcmF0aW9uVGltZW91dCI6NjAsIm1vZHVsYXJpemVJbXBvcnRzIjp7IkBtdWkvaWNvbnMtbWF0ZXJpYWwiOnsidHJhbnNmb3JtIjoiQG11aS9pY29ucy1tYXRlcmlhbC97e21lbWJlcn19In0sImxvZGFzaCI6eyJ0cmFuc2Zvcm0iOiJsb2Rhc2gve3ttZW1iZXJ9fSJ9fSwib3V0cHV0RmlsZVRyYWNpbmdSb290IjoiL3RtcC9uZXh0LXN0YXRzbXpKNE5TL3N0YXRzLWFwcCIsImV4cGVyaW1lbnRhbCI6eyJhcHBOYXZGYWlsSGFuZGxpbmciOmZhbHNlLCJwcmVyZW5kZXJFYXJseUV4aXQiOnRydWUsInNlcnZlck1pbmlmaWNhdGlvbiI6dHJ1ZSwic2VydmVyU291cmNlTWFwcyI6ZmFsc2UsImxpbmtOb1RvdWNoU3RhcnQiOmZhbHNlLCJjYXNlU2Vuc2l0aXZlUm91dGVzIjpmYWxzZSwicHJlbG9hZEVudHJpZXNPblN0YXJ0Ijp0cnVlLCJjbGllbnRSb3V0ZXJGaWx0ZXIiOnRydWUsImNsaWVudFJvdXRlckZpbHRlclJlZGlyZWN0cyI6ZmFsc2UsImZldGNoQ2FjaGVLZXlQcmVmaXgiOiIiLCJtaWRkbGV3YXJlUHJlZmV0Y2giOiJmbGV4aWJsZSIsIm9wdGltaXN0aWNDbGllbnRDYWNoZSI6dHJ1ZSwibWFudWFsQ2xpZW50QmFzZVBhdGgiOmZhbHNlLCJjcHVzIjoxOSwibWVtb3J5QmFzZWRXb3JrZXJzQ291bnQiOmZhbHNlLCJpc3JGbHVzaFRvRGlzayI6dHJ1ZSwid29ya2VyVGhyZWFkcyI6ZmFsc2UsIm9wdGltaXplQ3NzIjpmYWxzZSwibmV4dFNjcmlwdFdvcmtlcnMiOmZhbHNlLCJzY3JvbGxSZXN0b3JhdGlvbiI6ZmFsc2UsImV4dGVybmFsRGlyIjpmYWxzZSwiZGlzYWJsZU9wdGltaXplZExvYWRpbmciOmZhbHNlLCJnemlwU2l6ZSI6dHJ1ZSwiY3JhQ29tcGF0IjpmYWxzZSwiZXNtRXh0ZXJuYWxzIjp0cnVlLCJmdWxseVNwZWNpZmllZCI6ZmFsc2UsInN3Y1RyYWNlUHJvZmlsaW5nIjpmYWxzZSwiZm9yY2VTd2NUcmFuc2Zvcm1zIjpmYWxzZSwibGFyZ2VQYWdlRGF0YUJ5dGVzIjoxMjgwMDAsImFkanVzdEZvbnRGYWxsYmFja3MiOmZhbHNlLCJhZGp1c3RGb250RmFsbGJhY2tzV2l0aFNpemVBZGp1c3QiOmZhbHNlLCJ0eXBlZFJvdXRlcyI6ZmFsc2UsInR5cGVkRW52IjpmYWxzZSwiaW5zdHJ1bWVudGF0aW9uSG9vayI6ZmFsc2UsInBhcmFsbGVsU2VydmVyQ29tcGlsZXMiOmZhbHNlLCJwYXJhbGxlbFNlcnZlckJ1aWxkVHJhY2VzIjpmYWxzZSwicHByIjpmYWxzZSwid2VicGFja01lbW9yeU9wdGltaXphdGlvbnMiOmZhbHNlLCJvcHRpbWl6ZVNlcnZlclJlYWN0Ijp0cnVlLCJ1c2VFYXJseUltcG9ydCI6ZmFsc2UsInN0YWxlVGltZXMiOnsiZHluYW1pYyI6MCwic3RhdGljIjozMDB9LCJhZnRlciI6ZmFsc2UsInNlcnZlckNvbXBvbmVudHNIbXJDYWNoZSI6dHJ1ZSwic3RhdGljR2VuZXJhdGlvbk1heENvbmN1cnJlbmN5Ijo4LCJzdGF0aWNHZW5lcmF0aW9uTWluUGFnZXNQZXJXb3JrZXIiOjI1LCJvcHRpbWl6ZVBhY2thZ2VJbXBvcnRzIjpbImx1Y2lkZS1yZWFjdCIsImRhdGUtZm5zIiwibG9kYXNoLWVzIiwicmFtZGEiLCJhbnRkIiwicmVhY3QtYm9vdHN0cmFwIiwiYWhvb2tzIiwiQGFudC1kZXNpZ24vaWNvbnMiLCJAaGVhZGxlc3N1aS9yZWFjdCIsIkBoZWFkbGVzc3VpLWZsb2F0L3JlYWN0IiwiQGhlcm9pY29ucy9yZWFjdC8yMC9zb2xpZCIsIkBoZXJvaWNvbnMvcmVhY3QvMjQvc29saWQiLCJAaGVyb2ljb25zL3JlYWN0LzI0L291dGxpbmUiLCJAdmlzeC92aXN4IiwiQHRyZW1vci9yZWFjdCIsInJ4anMiLCJAbXVpL21hdGVyaWFsIiwiQG11aS9pY29ucy1tYXRlcmlhbCIsInJlY2hhcnRzIiwicmVhY3QtdXNlIiwiZWZmZWN0IiwiQGVmZmVjdC9zY2hlbWEiLCJAZWZmZWN0L3BsYXRmb3JtIiwiQGVmZmVjdC9wbGF0Zm9ybS1ub2RlIiwiQGVmZmVjdC9wbGF0Zm9ybS1icm93c2VyIiwiQGVmZmVjdC9wbGF0Zm9ybS1idW4iLCJAZWZmZWN0L3NxbCIsIkBlZmZlY3Qvc3FsLW1zc3FsIiwiQGVmZmVjdC9zcWwtbXlzcWwyIiwiQGVmZmVjdC9zcWwtcGciLCJAZWZmZWN0L3NxbC1zcXVsaXRlLW5vZGUiLCJAZWZmZWN0L3NxbC1zcXVsaXRlLWJ1biIsIkBlZmZlY3Qvc3FsLXNxdWxpdGUtd2FzbSIsIkBlZmZlY3Qvc3FsLXNxdWxpdGUtcmVhY3QtbmF0aXZlIiwiQGVmZmVjdC9ycGMiLCJAZWZmZWN0L3JwYy1odHRwIiwiQGVmZmVjdC90eXBlY2xhc3MiLCJAZWZmZWN0L2V4cGVyaW1lbnRhbCIsIkBlZmZlY3Qvb3BlbnRlbGVtZXRyeSIsIkBtYXRlcmlhbC11aS9jb3JlIiwiQG1hdGVyaWFsLXVpL2ljb25zIiwiQHRhYmxlci9pY29ucy1yZWFjdCIsIm11aS1jb3JlIiwicmVhY3QtaWNvbnMvYWkiLCJyZWFjdC1pY29ucy9iaSIsInJlYWN0LWljb25zL2JzIiwicmVhY3QtaWNvbnMvY2ciLCJyZWFjdC1pY29ucy9jaSIsInJlYWN0LWljb25zL2RpIiwicmVhY3QtaWNvbnMvZmEiLCJyZWFjdC1pY29ucy9mYTYiLCJyZWFjdC1pY29ucy9mYyIsInJlYWN0LWljb25zL2ZpIiwicmVhY3QtaWNvbnMvZ2kiLCJyZWFjdC1pY29ucy9nbyIsInJlYWN0LWljb25zL2dyIiwicmVhY3QtaWNvbnMvaGkiLCJyZWFjdC1pY29ucy9oaTIiLCJyZWFjdC1pY29ucy9pbSIsInJlYWN0LWljb25zL2lvIiwicmVhY3QtaWNvbnMvaW81IiwicmVhY3QtaWNvbnMvbGlhIiwicmVhY3QtaWNvbnMvbGliIiwicmVhY3QtaWNvbnMvbHUiLCJyZWFjdC1pY29ucy9tZCIsInJlYWN0LWljb25zL3BpIiwicmVhY3QtaWNvbnMvcmkiLCJyZWFjdC1pY29ucy9yeCIsInJlYWN0LWljb25zL3NpIiwicmVhY3QtaWNvbnMvc2wiLCJyZWFjdC1pY29ucy90YiIsInJlYWN0LWljb25zL3RmaSIsInJlYWN0LWljb25zL3RpIiwicmVhY3QtaWNvbnMvdnNjIiwicmVhY3QtaWNvbnMvd2kiXX0sImJ1bmRsZVBhZ2VzUm91dGVyRGVwZW5kZW5jaWVzIjpmYWxzZSwiY29uZmlnRmlsZSI6Ii90bXAvbmV4dC1zdGF0c216SjROUy9zdGF0cy1hcHAvbmV4dC5jb25maWcuanMiLCJjb25maWdGaWxlTmFtZSI6Im5leHQuY29uZmlnLmpzIn0=","pagesType":"app","appDirLoader":"bmV4dC1hcHAtbG9hZGVyP25hbWU9YXBwJTJGYXBwLWVkZ2Utc3NyJTJGcGFnZSZwYWdlPSUyRmFwcC1lZGdlLXNzciUyRnBhZ2UmcGFnZVBhdGg9cHJpdmF0ZS1uZXh0LWFwcC1kaXIlMkZhcHAtZWRnZS1zc3IlMkZwYWdlLmpzJmFwcERpcj0lMkZ0bXAlMkZuZXh0LXN0YXRzbXpKNE5TJTJGc3RhdHMtYXBwJTJGYXBwJmFwcFBhdGhzPSUyRmFwcC1lZGdlLXNzciUyRnBhZ2UmcGFnZUV4dGVuc2lvbnM9dHN4JnBhZ2VFeHRlbnNpb25zPXRzJnBhZ2VFeHRlbnNpb25zPWpzeCZwYWdlRXh0ZW5zaW9ucz1qcyZiYXNlUGF0aD0mYXNzZXRQcmVmaXg9Jm5leHRDb25maWdPdXRwdXQ9JmZseWluZ1NodXR0bGU9ZmFsc2UmcHJlZmVycmVkUmVnaW9uPSZtaWRkbGV3YXJlQ29uZmlnPWUzMCUzRCE=","sriEnabled":false,"middlewareConfig":"e30="}!
+      // EXTERNAL MODULE: ./node_modules/.pnpm/next@file+..+diff-repo+packages+next+next-packed.tgz_react-dom@19.0.0-rc-187dd6a7-20240806_re_wxf3je55uhqnotjiz3wkaonabu/node_modules/next/dist/esm/lib/page-types.js
+      var page_types = __webpack_require__(7709);
+      // EXTERNAL MODULE: ./node_modules/.pnpm/next@file+..+diff-repo+packages+next+next-packed.tgz_react-dom@19.0.0-rc-187dd6a7-20240806_re_wxf3je55uhqnotjiz3wkaonabu/node_modules/next/dist/esm/server/app-render/encryption-utils.js
+      var encryption_utils = __webpack_require__(6602);
+      // EXTERNAL MODULE: ./node_modules/.pnpm/next@file+..+diff-repo+packages+next+next-packed.tgz_react-dom@19.0.0-rc-187dd6a7-20240806_re_wxf3je55uhqnotjiz3wkaonabu/node_modules/next/dist/esm/server/app-render/action-utils.js
+      var action_utils = __webpack_require__(4137); // CONCATENATED MODULE: ./node_modules/.pnpm/next@file+..+diff-repo+packages+next+next-packed.tgz_react-dom@19.0.0-rc-187dd6a7-20240806_re_wxf3je55uhqnotjiz3wkaonabu/node_modules/next/dist/build/webpack/loaders/next-edge-ssr-loader/index.js?{"absolute500Path":"","absoluteAppPath":"next/dist/pages/_app","absoluteDocumentPath":"next/dist/pages/_document","absoluteErrorPath":"next/dist/pages/_error","absolutePagePath":"private-next-app-dir/app-edge-ssr/page.js","dev":false,"isServerComponent":true,"page":"/app-edge-ssr/page","stringifiedConfig":"eyJlbnYiOnt9LCJlc2xpbnQiOnsiaWdub3JlRHVyaW5nQnVpbGRzIjpmYWxzZX0sInR5cGVzY3JpcHQiOnsiaWdub3JlQnVpbGRFcnJvcnMiOmZhbHNlLCJ0c2NvbmZpZ1BhdGgiOiJ0c2NvbmZpZy5qc29uIn0sImRpc3REaXIiOiIubmV4dCIsImNsZWFuRGlzdERpciI6dHJ1ZSwiYXNzZXRQcmVmaXgiOiIiLCJjYWNoZU1heE1lbW9yeVNpemUiOjUyNDI4ODAwLCJjb25maWdPcmlnaW4iOiJuZXh0LmNvbmZpZy5qcyIsInVzZUZpbGVTeXN0ZW1QdWJsaWNSb3V0ZXMiOnRydWUsImdlbmVyYXRlRXRhZ3MiOnRydWUsInBhZ2VFeHRlbnNpb25zIjpbInRzeCIsInRzIiwianN4IiwianMiXSwicG93ZXJlZEJ5SGVhZGVyIjp0cnVlLCJjb21wcmVzcyI6dHJ1ZSwiaW1hZ2VzIjp7ImRldmljZVNpemVzIjpbNjQwLDc1MCw4MjgsMTA4MCwxMjAwLDE5MjAsMjA0OCwzODQwXSwiaW1hZ2VTaXplcyI6WzE2LDMyLDQ4LDY0LDk2LDEyOCwyNTYsMzg0XSwicGF0aCI6Ii9fbmV4dC9pbWFnZSIsImxvYWRlciI6ImRlZmF1bHQiLCJsb2FkZXJGaWxlIjoiIiwiZG9tYWlucyI6W10sImRpc2FibGVTdGF0aWNJbWFnZXMiOmZhbHNlLCJtaW5pbXVtQ2FjaGVUVEwiOjYwLCJmb3JtYXRzIjpbImltYWdlL3dlYnAiXSwiZGFuZ2Vyb3VzbHlBbGxvd1NWRyI6ZmFsc2UsImNvbnRlbnRTZWN1cml0eVBvbGljeSI6InNjcmlwdC1zcmMgJ25vbmUnOyBmcmFtZS1zcmMgJ25vbmUnOyBzYW5kYm94OyIsImNvbnRlbnREaXNwb3NpdGlvblR5cGUiOiJhdHRhY2htZW50IiwicmVtb3RlUGF0dGVybnMiOltdLCJ1bm9wdGltaXplZCI6ZmFsc2V9LCJkZXZJbmRpY2F0b3JzIjp7ImFwcElzclN0YXR1cyI6dHJ1ZSwiYnVpbGRBY3Rpdml0eSI6dHJ1ZSwiYnVpbGRBY3Rpdml0eVBvc2l0aW9uIjoiYm90dG9tLXJpZ2h0In0sIm9uRGVtYW5kRW50cmllcyI6eyJtYXhJbmFjdGl2ZUFnZSI6NjAwMDAsInBhZ2VzQnVmZmVyTGVuZ3RoIjo1fSwiYW1wIjp7ImNhbm9uaWNhbEJhc2UiOiIifSwiYmFzZVBhdGgiOiIiLCJzYXNzT3B0aW9ucyI6e30sInRyYWlsaW5nU2xhc2giOmZhbHNlLCJpMThuIjpudWxsLCJwcm9kdWN0aW9uQnJvd3NlclNvdXJjZU1hcHMiOmZhbHNlLCJvcHRpbWl6ZUZvbnRzIjp0cnVlLCJleGNsdWRlRGVmYXVsdE1vbWVudExvY2FsZXMiOnRydWUsInNlcnZlclJ1bnRpbWVDb25maWciOnt9LCJwdWJsaWNSdW50aW1lQ29uZmlnIjp7fSwicmVhY3RQcm9kdWN0aW9uUHJvZmlsaW5nIjpmYWxzZSwicmVhY3RTdHJpY3RNb2RlIjpudWxsLCJyZWFjdE1heEhlYWRlcnNMZW5ndGgiOjYwMDAsImh0dHBBZ2VudE9wdGlvbnMiOnsia2VlcEFsaXZlIjp0cnVlfSwibG9nZ2luZyI6e30sInN0YXRpY1BhZ2VHZW5lcmF0aW9uVGltZW91dCI6NjAsIm1vZHVsYXJpemVJbXBvcnRzIjp7IkBtdWkvaWNvbnMtbWF0ZXJpYWwiOnsidHJhbnNmb3JtIjoiQG11aS9pY29ucy1tYXRlcmlhbC97e21lbWJlcn19In0sImxvZGFzaCI6eyJ0cmFuc2Zvcm0iOiJsb2Rhc2gve3ttZW1iZXJ9fSJ9fSwib3V0cHV0RmlsZVRyYWNpbmdSb290IjoiL3RtcC9uZXh0LXN0YXRzbXpKNE5TL3N0YXRzLWFwcCIsImV4cGVyaW1lbnRhbCI6eyJhcHBOYXZGYWlsSGFuZGxpbmciOmZhbHNlLCJwcmVyZW5kZXJFYXJseUV4aXQiOnRydWUsInNlcnZlck1pbmlmaWNhdGlvbiI6dHJ1ZSwic2VydmVyU291cmNlTWFwcyI6ZmFsc2UsImxpbmtOb1RvdWNoU3RhcnQiOmZhbHNlLCJjYXNlU2Vuc2l0aXZlUm91dGVzIjpmYWxzZSwicHJlbG9hZEVudHJpZXNPblN0YXJ0Ijp0cnVlLCJjbGllbnRSb3V0ZXJGaWx0ZXIiOnRydWUsImNsaWVudFJvdXRlckZpbHRlclJlZGlyZWN0cyI6ZmFsc2UsImZldGNoQ2FjaGVLZXlQcmVmaXgiOiIiLCJtaWRkbGV3YXJlUHJlZmV0Y2giOiJmbGV4aWJsZSIsIm9wdGltaXN0aWNDbGllbnRDYWNoZSI6dHJ1ZSwibWFudWFsQ2xpZW50QmFzZVBhdGgiOmZhbHNlLCJjcHVzIjoxOSwibWVtb3J5QmFzZWRXb3JrZXJzQ291bnQiOmZhbHNlLCJpc3JGbHVzaFRvRGlzayI6dHJ1ZSwid29ya2VyVGhyZWFkcyI6ZmFsc2UsIm9wdGltaXplQ3NzIjpmYWxzZSwibmV4dFNjcmlwdFdvcmtlcnMiOmZhbHNlLCJzY3JvbGxSZXN0b3JhdGlvbiI6ZmFsc2UsImV4dGVybmFsRGlyIjpmYWxzZSwiZGlzYWJsZU9wdGltaXplZExvYWRpbmciOmZhbHNlLCJnemlwU2l6ZSI6dHJ1ZSwiY3JhQ29tcGF0IjpmYWxzZSwiZXNtRXh0ZXJuYWxzIjp0cnVlLCJmdWxseVNwZWNpZmllZCI6ZmFsc2UsInN3Y1RyYWNlUHJvZmlsaW5nIjpmYWxzZSwiZm9yY2VTd2NUcmFuc2Zvcm1zIjpmYWxzZSwibGFyZ2VQYWdlRGF0YUJ5dGVzIjoxMjgwMDAsImFkanVzdEZvbnRGYWxsYmFja3MiOmZhbHNlLCJhZGp1c3RGb250RmFsbGJhY2tzV2l0aFNpemVBZGp1c3QiOmZhbHNlLCJ0eXBlZFJvdXRlcyI6ZmFsc2UsInR5cGVkRW52IjpmYWxzZSwiaW5zdHJ1bWVudGF0aW9uSG9vayI6ZmFsc2UsInBhcmFsbGVsU2VydmVyQ29tcGlsZXMiOmZhbHNlLCJwYXJhbGxlbFNlcnZlckJ1aWxkVHJhY2VzIjpmYWxzZSwicHByIjpmYWxzZSwid2VicGFja01lbW9yeU9wdGltaXphdGlvbnMiOmZhbHNlLCJvcHRpbWl6ZVNlcnZlclJlYWN0Ijp0cnVlLCJ1c2VFYXJseUltcG9ydCI6ZmFsc2UsInN0YWxlVGltZXMiOnsiZHluYW1pYyI6MCwic3RhdGljIjozMDB9LCJhZnRlciI6ZmFsc2UsInNlcnZlckNvbXBvbmVudHNIbXJDYWNoZSI6dHJ1ZSwic3RhdGljR2VuZXJhdGlvbk1heENvbmN1cnJlbmN5Ijo4LCJzdGF0aWNHZW5lcmF0aW9uTWluUGFnZXNQZXJXb3JrZXIiOjI1LCJvcHRpbWl6ZVBhY2thZ2VJbXBvcnRzIjpbImx1Y2lkZS1yZWFjdCIsImRhdGUtZm5zIiwibG9kYXNoLWVzIiwicmFtZGEiLCJhbnRkIiwicmVhY3QtYm9vdHN0cmFwIiwiYWhvb2tzIiwiQGFudC1kZXNpZ24vaWNvbnMiLCJAaGVhZGxlc3N1aS9yZWFjdCIsIkBoZWFkbGVzc3VpLWZsb2F0L3JlYWN0IiwiQGhlcm9pY29ucy9yZWFjdC8yMC9zb2xpZCIsIkBoZXJvaWNvbnMvcmVhY3QvMjQvc29saWQiLCJAaGVyb2ljb25zL3JlYWN0LzI0L291dGxpbmUiLCJAdmlzeC92aXN4IiwiQHRyZW1vci9yZWFjdCIsInJ4anMiLCJAbXVpL21hdGVyaWFsIiwiQG11aS9pY29ucy1tYXRlcmlhbCIsInJlY2hhcnRzIiwicmVhY3QtdXNlIiwiZWZmZWN0IiwiQGVmZmVjdC9zY2hlbWEiLCJAZWZmZWN0L3BsYXRmb3JtIiwiQGVmZmVjdC9wbGF0Zm9ybS1ub2RlIiwiQGVmZmVjdC9wbGF0Zm9ybS1icm93c2VyIiwiQGVmZmVjdC9wbGF0Zm9ybS1idW4iLCJAZWZmZWN0L3NxbCIsIkBlZmZlY3Qvc3FsLW1zc3FsIiwiQGVmZmVjdC9zcWwtbXlzcWwyIiwiQGVmZmVjdC9zcWwtcGciLCJAZWZmZWN0L3NxbC1zcXVsaXRlLW5vZGUiLCJAZWZmZWN0L3NxbC1zcXVsaXRlLWJ1biIsIkBlZmZlY3Qvc3FsLXNxdWxpdGUtd2FzbSIsIkBlZmZlY3Qvc3FsLXNxdWxpdGUtcmVhY3QtbmF0aXZlIiwiQGVmZmVjdC9ycGMiLCJAZWZmZWN0L3JwYy1odHRwIiwiQGVmZmVjdC90eXBlY2xhc3MiLCJAZWZmZWN0L2V4cGVyaW1lbnRhbCIsIkBlZmZlY3Qvb3BlbnRlbGVtZXRyeSIsIkBtYXRlcmlhbC11aS9jb3JlIiwiQG1hdGVyaWFsLXVpL2ljb25zIiwiQHRhYmxlci9pY29ucy1yZWFjdCIsIm11aS1jb3JlIiwicmVhY3QtaWNvbnMvYWkiLCJyZWFjdC1pY29ucy9iaSIsInJlYWN0LWljb25zL2JzIiwicmVhY3QtaWNvbnMvY2ciLCJyZWFjdC1pY29ucy9jaSIsInJlYWN0LWljb25zL2RpIiwicmVhY3QtaWNvbnMvZmEiLCJyZWFjdC1pY29ucy9mYTYiLCJyZWFjdC1pY29ucy9mYyIsInJlYWN0LWljb25zL2ZpIiwicmVhY3QtaWNvbnMvZ2kiLCJyZWFjdC1pY29ucy9nbyIsInJlYWN0LWljb25zL2dyIiwicmVhY3QtaWNvbnMvaGkiLCJyZWFjdC1pY29ucy9oaTIiLCJyZWFjdC1pY29ucy9pbSIsInJlYWN0LWljb25zL2lvIiwicmVhY3QtaWNvbnMvaW81IiwicmVhY3QtaWNvbnMvbGlhIiwicmVhY3QtaWNvbnMvbGliIiwicmVhY3QtaWNvbnMvbHUiLCJyZWFjdC1pY29ucy9tZCIsInJlYWN0LWljb25zL3BpIiwicmVhY3QtaWNvbnMvcmkiLCJyZWFjdC1pY29ucy9yeCIsInJlYWN0LWljb25zL3NpIiwicmVhY3QtaWNvbnMvc2wiLCJyZWFjdC1pY29ucy90YiIsInJlYWN0LWljb25zL3RmaSIsInJlYWN0LWljb25zL3RpIiwicmVhY3QtaWNvbnMvdnNjIiwicmVhY3QtaWNvbnMvd2kiXX0sImJ1bmRsZVBhZ2VzUm91dGVyRGVwZW5kZW5jaWVzIjpmYWxzZSwiY29uZmlnRmlsZSI6Ii90bXAvbmV4dC1zdGF0c216SjROUy9zdGF0cy1hcHAvbmV4dC5jb25maWcuanMiLCJjb25maWdGaWxlTmFtZSI6Im5leHQuY29uZmlnLmpzIn0=","pagesType":"app","appDirLoader":"bmV4dC1hcHAtbG9hZGVyP25hbWU9YXBwJTJGYXBwLWVkZ2Utc3NyJTJGcGFnZSZwYWdlPSUyRmFwcC1lZGdlLXNzciUyRnBhZ2UmcGFnZVBhdGg9cHJpdmF0ZS1uZXh0LWFwcC1kaXIlMkZhcHAtZWRnZS1zc3IlMkZwYWdlLmpzJmFwcERpcj0lMkZ0bXAlMkZuZXh0LXN0YXRzbXpKNE5TJTJGc3RhdHMtYXBwJTJGYXBwJmFwcFBhdGhzPSUyRmFwcC1lZGdlLXNzciUyRnBhZ2UmcGFnZUV4dGVuc2lvbnM9dHN4JnBhZ2VFeHRlbnNpb25zPXRzJnBhZ2VFeHRlbnNpb25zPWpzeCZwYWdlRXh0ZW5zaW9ucz1qcyZiYXNlUGF0aD0mYXNzZXRQcmVmaXg9Jm5leHRDb25maWdPdXRwdXQ9JmZseWluZ1NodXR0bGU9ZmFsc2UmcHJlZmVycmVkUmVnaW9uPSZtaWRkbGV3YXJlQ29uZmlnPWUzMCUzRCE=","sriEnabled":false,"middlewareConfig":"e30="}!
       var _self___RSC_MANIFEST;
 
       const incrementalCacheHandler = null;
@@ -429,50 +429,50 @@
       /***/
     },
 
-    /***/ 351: /***/ (
+    /***/ 2701: /***/ (
       __unused_webpack_module,
       __unused_webpack_exports,
       __webpack_require__
     ) => {
       Promise.resolve(/* import() eager */).then(
-        __webpack_require__.bind(__webpack_require__, 1862)
+        __webpack_require__.bind(__webpack_require__, 8368)
       );
       Promise.resolve(/* import() eager */).then(
-        __webpack_require__.bind(__webpack_require__, 5625)
+        __webpack_require__.bind(__webpack_require__, 5861)
       );
       Promise.resolve(/* import() eager */).then(
-        __webpack_require__.bind(__webpack_require__, 9390)
+        __webpack_require__.bind(__webpack_require__, 8878)
       );
       Promise.resolve(/* import() eager */).then(
-        __webpack_require__.bind(__webpack_require__, 7785)
+        __webpack_require__.bind(__webpack_require__, 2622)
       );
       Promise.resolve(/* import() eager */).then(
-        __webpack_require__.bind(__webpack_require__, 4618)
+        __webpack_require__.bind(__webpack_require__, 5212)
       );
       Promise.resolve(/* import() eager */).then(
-        __webpack_require__.bind(__webpack_require__, 3974)
+        __webpack_require__.bind(__webpack_require__, 4381)
       );
       Promise.resolve(/* import() eager */).then(
-        __webpack_require__.bind(__webpack_require__, 273)
+        __webpack_require__.bind(__webpack_require__, 6577)
       );
       Promise.resolve(/* import() eager */).then(
-        __webpack_require__.bind(__webpack_require__, 1264)
+        __webpack_require__.bind(__webpack_require__, 6373)
       );
       Promise.resolve(/* import() eager */).then(
-        __webpack_require__.bind(__webpack_require__, 6945)
+        __webpack_require__.bind(__webpack_require__, 3208)
       );
       Promise.resolve(/* import() eager */).then(
-        __webpack_require__.bind(__webpack_require__, 5257)
+        __webpack_require__.bind(__webpack_require__, 1774)
       );
 
       /***/
     },
 
-    /***/ 6295: /***/ () => {
+    /***/ 4177: /***/ () => {
       /***/
     },
 
-    /***/ 7310: /***/ (
+    /***/ 3689: /***/ (
       __unused_webpack_module,
       __webpack_exports__,
       __webpack_require__
@@ -492,7 +492,7 @@
       /***/
     },
 
-    /***/ 3876: /***/ (
+    /***/ 5490: /***/ (
       __unused_webpack_module,
       __webpack_exports__,
       __webpack_require__
@@ -504,7 +504,7 @@
         /* harmony export */
       });
       /* harmony import */ var react_jsx_runtime__WEBPACK_IMPORTED_MODULE_0__ =
-        __webpack_require__(628);
+        __webpack_require__(8150);
 
       function RootLayout({ children }) {
         return /*#__PURE__*/ (0,
@@ -523,7 +523,7 @@
     // webpackRuntimeModules
     /******/ var __webpack_exec__ = (moduleId) =>
       __webpack_require__((__webpack_require__.s = moduleId));
-    /******/ __webpack_require__.O(0, [696, 560], () => __webpack_exec__(1398));
+    /******/ __webpack_require__.O(0, [611, 327], () => __webpack_exec__(73));
     /******/ var __webpack_exports__ = __webpack_require__.O();
     /******/ (_ENTRIES = typeof _ENTRIES === "undefined" ? {} : _ENTRIES)[
       "middleware_app/app-edge-ssr/page"
Diff for middleware.js

Diff too large to display

Diff for edge-ssr.js

Diff too large to display

Diff for image-HASH.js 
@@ -1,7 +1,7 @@
 (self["webpackChunk_N_E"] = self["webpackChunk_N_E"] || []).push([
   [8358],
   {
-    /***/ 9842: /***/ (
+    /***/ 5684: /***/ (
       __unused_webpack_module,
       __unused_webpack_exports,
       __webpack_require__
@@ -9,7 +9,7 @@
       (window.__NEXT_P = window.__NEXT_P || []).push([
         "/image",
         function () {
-          return __webpack_require__(8722);
+          return __webpack_require__(2665);
         },
       ]);
       if (false) {
@@ -18,7 +18,7 @@
       /***/
     },
 
-    /***/ 5040: /***/ (module, exports, __webpack_require__) => {
+    /***/ 3608: /***/ (module, exports, __webpack_require__) => {
       "use strict";
       /* __next_internal_client_entry_do_not_use__  cjs */
       Object.defineProperty(exports, "__esModule", {
@@ -40,17 +40,17 @@
         __webpack_require__(2957)
       );
       const _head = /*#__PURE__*/ _interop_require_default._(
-        __webpack_require__(5187)
+        __webpack_require__(7569)
       );
-      const _getimgprops = __webpack_require__(1332);
-      const _imageconfig = __webpack_require__(3384);
-      const _imageconfigcontextsharedruntime = __webpack_require__(8875);
-      const _warnonce = __webpack_require__(4516);
-      const _routercontextsharedruntime = __webpack_require__(5002);
+      const _getimgprops = __webpack_require__(4429);
+      const _imageconfig = __webpack_require__(2950);
+      const _imageconfigcontextsharedruntime = __webpack_require__(6587);
+      const _warnonce = __webpack_require__(8719);
+      const _routercontextsharedruntime = __webpack_require__(2062);
       const _imageloader = /*#__PURE__*/ _interop_require_default._(
-        __webpack_require__(5145)
+        __webpack_require__(232)
       );
-      const _usemergedref = __webpack_require__(4926);
+      const _usemergedref = __webpack_require__(9935);
       // This is replaced by webpack define plugin
       const configEnv = {
         deviceSizes: [640, 750, 828, 1080, 1200, 1920, 2048, 3840],
@@ -371,7 +371,7 @@
       /***/
     },
 
-    /***/ 4926: /***/ (module, exports, __webpack_require__) => {
+    /***/ 9935: /***/ (module, exports, __webpack_require__) => {
       "use strict";
 
       Object.defineProperty(exports, "__esModule", {
@@ -440,7 +440,7 @@
       /***/
     },
 
-    /***/ 1332: /***/ (
+    /***/ 4429: /***/ (
       __unused_webpack_module,
       exports,
       __webpack_require__
@@ -456,9 +456,9 @@
           return getImgProps;
         },
       });
-      const _warnonce = __webpack_require__(4516);
-      const _imageblursvg = __webpack_require__(1569);
-      const _imageconfig = __webpack_require__(3384);
+      const _warnonce = __webpack_require__(8719);
+      const _imageblursvg = __webpack_require__(3207);
+      const _imageconfig = __webpack_require__(2950);
       const VALID_LOADING_VALUES =
         /* unused pure expression or super */ null && [
           "lazy",
@@ -830,7 +830,7 @@
       /***/
     },
 
-    /***/ 1569: /***/ (__unused_webpack_module, exports) => {
+    /***/ 3207: /***/ (__unused_webpack_module, exports) => {
       "use strict";
       /**
        * A shared function, used on both client and server, to generate a SVG blur placeholder.
@@ -885,7 +885,7 @@
       /***/
     },
 
-    /***/ 1674: /***/ (
+    /***/ 3455: /***/ (
       __unused_webpack_module,
       exports,
       __webpack_require__
@@ -912,10 +912,10 @@
         },
       });
       const _interop_require_default = __webpack_require__(4345);
-      const _getimgprops = __webpack_require__(1332);
-      const _imagecomponent = __webpack_require__(5040);
+      const _getimgprops = __webpack_require__(4429);
+      const _imagecomponent = __webpack_require__(3608);
       const _imageloader = /*#__PURE__*/ _interop_require_default._(
-        __webpack_require__(5145)
+        __webpack_require__(232)
       );
       function getImageProps(imgProps) {
         const { props } = (0, _getimgprops.getImgProps)(imgProps, {
@@ -947,7 +947,7 @@
       /***/
     },
 
-    /***/ 5145: /***/ (__unused_webpack_module, exports) => {
+    /***/ 232: /***/ (__unused_webpack_module, exports) => {
       "use strict";
 
       Object.defineProperty(exports, "__esModule", {
@@ -982,7 +982,7 @@
       /***/
     },
 
-    /***/ 8722: /***/ (
+    /***/ 2665: /***/ (
       __unused_webpack_module,
       __webpack_exports__,
       __webpack_require__
@@ -999,8 +999,8 @@
 
       // EXTERNAL MODULE: ./node_modules/.pnpm/[email protected]/node_modules/react/jsx-runtime.js
       var jsx_runtime = __webpack_require__(8548);
-      // EXTERNAL MODULE: ./node_modules/.pnpm/next@file+..+main-repo+packages+next+next-packed.tgz_react-dom@19.0.0-rc-187dd6a7-20240806_re_6tugpsz4gl2xsqrwds5bwcbi3y/node_modules/next/image.js
-      var next_image = __webpack_require__(6629);
+      // EXTERNAL MODULE: ./node_modules/.pnpm/next@file+..+diff-repo+packages+next+next-packed.tgz_react-dom@19.0.0-rc-187dd6a7-20240806_re_wxf3je55uhqnotjiz3wkaonabu/node_modules/next/image.js
+      var next_image = __webpack_require__(2856);
       var image_default = /*#__PURE__*/ __webpack_require__.n(next_image); // CONCATENATED MODULE: ./pages/nextjs.png
       /* harmony default export */ const nextjs = {
         src: "/_next/static/media/nextjs.cae0b805.png",
@@ -1030,12 +1030,12 @@
       /***/
     },
 
-    /***/ 6629: /***/ (
+    /***/ 2856: /***/ (
       module,
       __unused_webpack_exports,
       __webpack_require__
     ) => {
-      module.exports = __webpack_require__(1674);
+      module.exports = __webpack_require__(3455);
 
       /***/
     },
@@ -1045,7 +1045,7 @@
     /******/ var __webpack_exec__ = (moduleId) =>
       __webpack_require__((__webpack_require__.s = moduleId));
     /******/ __webpack_require__.O(0, [2888, 9774, 179], () =>
-      __webpack_exec__(9842)
+      __webpack_exec__(5684)
     );
     /******/ var __webpack_exports__ = __webpack_require__.O();
     /******/ _N_E = __webpack_exports__;
Diff for 8711-HASH.js

Diff too large to display

Diff for main-HASH.js

Diff too large to display

Commit: b1d5270

@ztanner ztanner force-pushed the 08-15-fix_i18n_data_pathname_resolving branch from f7a4e93 to 2b01bc8 Compare August 15, 2024 16:50
@ztanner ztanner force-pushed the 08-15-fix_i18n_data_pathname_resolving branch 2 times, most recently from 8bec06a to 1b9e048 Compare August 15, 2024 22:16
@ztanner ztanner marked this pull request as ready for review August 15, 2024 22:34
@ztanner ztanner requested a review from ijjk August 15, 2024 22:34
@ztanner ztanner enabled auto-merge (squash) August 15, 2024 22:55
@ztanner ztanner merged commit 53a20d7 into canary Aug 15, 2024
109 of 111 checks passed
@ztanner ztanner deleted the 08-15-fix_i18n_data_pathname_resolving branch August 15, 2024 23:05
lubieowoce pushed a commit that referenced this pull request Aug 22, 2024
@ztanner @lubieowoce
fix i18n data pathname resolving (#68947)
b33df13 
### What
When using middleware + i18n in pages router, and upon navigation to a
dynamic route, the wrong locale would be served in `getServerSideProps`.

### Why
The route resolver code handles detecting the initial locale by
splitting the path and looking at the first non-empty index to determine
which locale was set. However, it does this assuming it has a regular
path name, and not a `/_next/data` URL.

When middleware is present, the route resolver code hits the
`middleware_next_data` branch, which doesn't have any logic to properly
set the locale. This means that resolveRoutes will return the default
locale rather than the locale from the path.

In the non-middleware case, this would normally flow through
`handleNextDataRequest` in base-server which has handling to infer i18n
via `i18nProvider`. This branch is functionally very similar to what
we're doing in `resolveRoutes` but it does so in a different way: it
reconstructs the URL without the `/_next/data` information and then
attaches locale information. However because `middleware_next_data`
rewrites the pathname to the actual route (ie
`/_next/data/development/foo.json` -> `/foo`), `handleNextDataRequest`
won't handle that request since it's no longer a data request.

It's strange to me that `handleNextDataRequest` and
`middleware_next_data` are doing similar path normalization in
completely different ways, but that was a deeper rabbit hole and simply
removing the normalization logic in `resolveRoutes` causes other
problems.

### How
Since data requests that flow through this middleware matcher logic
aren't going to be handled by `handleNextDataRequest`, I've updated
`middleware_next_data` to perform the logic of attaching the locale
information to the query. Initially I was going to do this for anything
that calls `normalizeLocalePath` but it seems like other branches of
`resolveRoutes` do it in the matcher function directly.

Fixes #54217
Closes NDX-116
lubieowoce pushed a commit that referenced this pull request Aug 22, 2024
@ztanner @lubieowoce
fix i18n data pathname resolving (#68947)
e29ae44 
### What
When using middleware + i18n in pages router, and upon navigation to a
dynamic route, the wrong locale would be served in `getServerSideProps`.

### Why
The route resolver code handles detecting the initial locale by
splitting the path and looking at the first non-empty index to determine
which locale was set. However, it does this assuming it has a regular
path name, and not a `/_next/data` URL.

When middleware is present, the route resolver code hits the
`middleware_next_data` branch, which doesn't have any logic to properly
set the locale. This means that resolveRoutes will return the default
locale rather than the locale from the path.

In the non-middleware case, this would normally flow through
`handleNextDataRequest` in base-server which has handling to infer i18n
via `i18nProvider`. This branch is functionally very similar to what
we're doing in `resolveRoutes` but it does so in a different way: it
reconstructs the URL without the `/_next/data` information and then
attaches locale information. However because `middleware_next_data`
rewrites the pathname to the actual route (ie
`/_next/data/development/foo.json` -> `/foo`), `handleNextDataRequest`
won't handle that request since it's no longer a data request.

It's strange to me that `handleNextDataRequest` and
`middleware_next_data` are doing similar path normalization in
completely different ways, but that was a deeper rabbit hole and simply
removing the normalization logic in `resolveRoutes` causes other
problems.

### How
Since data requests that flow through this middleware matcher logic
aren't going to be handled by `handleNextDataRequest`, I've updated
`middleware_next_data` to perform the logic of attaching the locale
information to the query. Initially I was going to do this for anything
that calls `normalizeLocalePath` but it seems like other branches of
`resolveRoutes` do it in the matcher function directly.

Fixes #54217
Closes NDX-116
lubieowoce pushed a commit that referenced this pull request Aug 22, 2024
@ztanner @lubieowoce
fix i18n data pathname resolving (#68947)
2aa09c4 
### What
When using middleware + i18n in pages router, and upon navigation to a
dynamic route, the wrong locale would be served in `getServerSideProps`.

### Why
The route resolver code handles detecting the initial locale by
splitting the path and looking at the first non-empty index to determine
which locale was set. However, it does this assuming it has a regular
path name, and not a `/_next/data` URL.

When middleware is present, the route resolver code hits the
`middleware_next_data` branch, which doesn't have any logic to properly
set the locale. This means that resolveRoutes will return the default
locale rather than the locale from the path.

In the non-middleware case, this would normally flow through
`handleNextDataRequest` in base-server which has handling to infer i18n
via `i18nProvider`. This branch is functionally very similar to what
we're doing in `resolveRoutes` but it does so in a different way: it
reconstructs the URL without the `/_next/data` information and then
attaches locale information. However because `middleware_next_data`
rewrites the pathname to the actual route (ie
`/_next/data/development/foo.json` -> `/foo`), `handleNextDataRequest`
won't handle that request since it's no longer a data request.

It's strange to me that `handleNextDataRequest` and
`middleware_next_data` are doing similar path normalization in
completely different ways, but that was a deeper rabbit hole and simply
removing the normalization logic in `resolveRoutes` causes other
problems.

### How
Since data requests that flow through this middleware matcher logic
aren't going to be handled by `handleNextDataRequest`, I've updated
`middleware_next_data` to perform the logic of attaching the locale
information to the query. Initially I was going to do this for anything
that calls `normalizeLocalePath` but it seems like other branches of
`resolveRoutes` do it in the matcher function directly.

Fixes #54217
Closes NDX-116
lubieowoce pushed a commit that referenced this pull request Aug 22, 2024
@ztanner @lubieowoce
fix i18n data pathname resolving (#68947)
4e4f93b 
### What
When using middleware + i18n in pages router, and upon navigation to a
dynamic route, the wrong locale would be served in `getServerSideProps`.

### Why
The route resolver code handles detecting the initial locale by
splitting the path and looking at the first non-empty index to determine
which locale was set. However, it does this assuming it has a regular
path name, and not a `/_next/data` URL.

When middleware is present, the route resolver code hits the
`middleware_next_data` branch, which doesn't have any logic to properly
set the locale. This means that resolveRoutes will return the default
locale rather than the locale from the path.

In the non-middleware case, this would normally flow through
`handleNextDataRequest` in base-server which has handling to infer i18n
via `i18nProvider`. This branch is functionally very similar to what
we're doing in `resolveRoutes` but it does so in a different way: it
reconstructs the URL without the `/_next/data` information and then
attaches locale information. However because `middleware_next_data`
rewrites the pathname to the actual route (ie
`/_next/data/development/foo.json` -> `/foo`), `handleNextDataRequest`
won't handle that request since it's no longer a data request.

It's strange to me that `handleNextDataRequest` and
`middleware_next_data` are doing similar path normalization in
completely different ways, but that was a deeper rabbit hole and simply
removing the normalization logic in `resolveRoutes` causes other
problems.

### How
Since data requests that flow through this middleware matcher logic
aren't going to be handled by `handleNextDataRequest`, I've updated
`middleware_next_data` to perform the logic of attaching the locale
information to the query. Initially I was going to do this for anything
that calls `normalizeLocalePath` but it seems like other branches of
`resolveRoutes` do it in the matcher function directly.

Fixes #54217
Closes NDX-116
lubieowoce pushed a commit that referenced this pull request Aug 22, 2024
@ztanner @lubieowoce
fix i18n data pathname resolving (#68947)
a5b6028 
### What
When using middleware + i18n in pages router, and upon navigation to a
dynamic route, the wrong locale would be served in `getServerSideProps`.

### Why
The route resolver code handles detecting the initial locale by
splitting the path and looking at the first non-empty index to determine
which locale was set. However, it does this assuming it has a regular
path name, and not a `/_next/data` URL.

When middleware is present, the route resolver code hits the
`middleware_next_data` branch, which doesn't have any logic to properly
set the locale. This means that resolveRoutes will return the default
locale rather than the locale from the path.

In the non-middleware case, this would normally flow through
`handleNextDataRequest` in base-server which has handling to infer i18n
via `i18nProvider`. This branch is functionally very similar to what
we're doing in `resolveRoutes` but it does so in a different way: it
reconstructs the URL without the `/_next/data` information and then
attaches locale information. However because `middleware_next_data`
rewrites the pathname to the actual route (ie
`/_next/data/development/foo.json` -> `/foo`), `handleNextDataRequest`
won't handle that request since it's no longer a data request.

It's strange to me that `handleNextDataRequest` and
`middleware_next_data` are doing similar path normalization in
completely different ways, but that was a deeper rabbit hole and simply
removing the normalization logic in `resolveRoutes` causes other
problems.

### How
Since data requests that flow through this middleware matcher logic
aren't going to be handled by `handleNextDataRequest`, I've updated
`middleware_next_data` to perform the logic of attaching the locale
information to the query. Initially I was going to do this for anything
that calls `normalizeLocalePath` but it seems like other branches of
`resolveRoutes` do it in the matcher function directly.

Fixes #54217
Closes NDX-116
lubieowoce pushed a commit that referenced this pull request Aug 22, 2024
@ztanner @lubieowoce
fix i18n data pathname resolving (#68947)
6349864 
### What
When using middleware + i18n in pages router, and upon navigation to a
dynamic route, the wrong locale would be served in `getServerSideProps`.

### Why
The route resolver code handles detecting the initial locale by
splitting the path and looking at the first non-empty index to determine
which locale was set. However, it does this assuming it has a regular
path name, and not a `/_next/data` URL.

When middleware is present, the route resolver code hits the
`middleware_next_data` branch, which doesn't have any logic to properly
set the locale. This means that resolveRoutes will return the default
locale rather than the locale from the path.

In the non-middleware case, this would normally flow through
`handleNextDataRequest` in base-server which has handling to infer i18n
via `i18nProvider`. This branch is functionally very similar to what
we're doing in `resolveRoutes` but it does so in a different way: it
reconstructs the URL without the `/_next/data` information and then
attaches locale information. However because `middleware_next_data`
rewrites the pathname to the actual route (ie
`/_next/data/development/foo.json` -> `/foo`), `handleNextDataRequest`
won't handle that request since it's no longer a data request.

It's strange to me that `handleNextDataRequest` and
`middleware_next_data` are doing similar path normalization in
completely different ways, but that was a deeper rabbit hole and simply
removing the normalization logic in `resolveRoutes` causes other
problems.

### How
Since data requests that flow through this middleware matcher logic
aren't going to be handled by `handleNextDataRequest`, I've updated
`middleware_next_data` to perform the logic of attaching the locale
information to the query. Initially I was going to do this for anything
that calls `normalizeLocalePath` but it seems like other branches of
`resolveRoutes` do it in the matcher function directly.

Fixes #54217
Closes NDX-116
lubieowoce pushed a commit that referenced this pull request Aug 22, 2024
@ztanner @lubieowoce
fix i18n data pathname resolving (#68947)
8677a3a 
### What
When using middleware + i18n in pages router, and upon navigation to a
dynamic route, the wrong locale would be served in `getServerSideProps`.

### Why
The route resolver code handles detecting the initial locale by
splitting the path and looking at the first non-empty index to determine
which locale was set. However, it does this assuming it has a regular
path name, and not a `/_next/data` URL.

When middleware is present, the route resolver code hits the
`middleware_next_data` branch, which doesn't have any logic to properly
set the locale. This means that resolveRoutes will return the default
locale rather than the locale from the path.

In the non-middleware case, this would normally flow through
`handleNextDataRequest` in base-server which has handling to infer i18n
via `i18nProvider`. This branch is functionally very similar to what
we're doing in `resolveRoutes` but it does so in a different way: it
reconstructs the URL without the `/_next/data` information and then
attaches locale information. However because `middleware_next_data`
rewrites the pathname to the actual route (ie
`/_next/data/development/foo.json` -> `/foo`), `handleNextDataRequest`
won't handle that request since it's no longer a data request.

It's strange to me that `handleNextDataRequest` and
`middleware_next_data` are doing similar path normalization in
completely different ways, but that was a deeper rabbit hole and simply
removing the normalization logic in `resolveRoutes` causes other
problems.

### How
Since data requests that flow through this middleware matcher logic
aren't going to be handled by `handleNextDataRequest`, I've updated
`middleware_next_data` to perform the logic of attaching the locale
information to the query. Initially I was going to do this for anything
that calls `normalizeLocalePath` but it seems like other branches of
`resolveRoutes` do it in the matcher function directly.

Fixes #54217
Closes NDX-116
lubieowoce pushed a commit that referenced this pull request Aug 23, 2024
@ztanner @lubieowoce
fix i18n data pathname resolving (#68947)
677cf36 
### What
When using middleware + i18n in pages router, and upon navigation to a
dynamic route, the wrong locale would be served in `getServerSideProps`.

### Why
The route resolver code handles detecting the initial locale by
splitting the path and looking at the first non-empty index to determine
which locale was set. However, it does this assuming it has a regular
path name, and not a `/_next/data` URL.

When middleware is present, the route resolver code hits the
`middleware_next_data` branch, which doesn't have any logic to properly
set the locale. This means that resolveRoutes will return the default
locale rather than the locale from the path.

In the non-middleware case, this would normally flow through
`handleNextDataRequest` in base-server which has handling to infer i18n
via `i18nProvider`. This branch is functionally very similar to what
we're doing in `resolveRoutes` but it does so in a different way: it
reconstructs the URL without the `/_next/data` information and then
attaches locale information. However because `middleware_next_data`
rewrites the pathname to the actual route (ie
`/_next/data/development/foo.json` -> `/foo`), `handleNextDataRequest`
won't handle that request since it's no longer a data request.

It's strange to me that `handleNextDataRequest` and
`middleware_next_data` are doing similar path normalization in
completely different ways, but that was a deeper rabbit hole and simply
removing the normalization logic in `resolveRoutes` causes other
problems.

### How
Since data requests that flow through this middleware matcher logic
aren't going to be handled by `handleNextDataRequest`, I've updated
`middleware_next_data` to perform the logic of attaching the locale
information to the query. Initially I was going to do this for anything
that calls `normalizeLocalePath` but it seems like other branches of
`resolveRoutes` do it in the matcher function directly.

Fixes #54217
Closes NDX-116
ztanner added a commit that referenced this pull request Aug 26, 2024
@ztanner
fix i18n data pathname resolving (#68947)
5e6f511 
### What
When using middleware + i18n in pages router, and upon navigation to a
dynamic route, the wrong locale would be served in `getServerSideProps`.

### Why
The route resolver code handles detecting the initial locale by
splitting the path and looking at the first non-empty index to determine
which locale was set. However, it does this assuming it has a regular
path name, and not a `/_next/data` URL.

When middleware is present, the route resolver code hits the
`middleware_next_data` branch, which doesn't have any logic to properly
set the locale. This means that resolveRoutes will return the default
locale rather than the locale from the path.

In the non-middleware case, this would normally flow through
`handleNextDataRequest` in base-server which has handling to infer i18n
via `i18nProvider`. This branch is functionally very similar to what
we're doing in `resolveRoutes` but it does so in a different way: it
reconstructs the URL without the `/_next/data` information and then
attaches locale information. However because `middleware_next_data`
rewrites the pathname to the actual route (ie
`/_next/data/development/foo.json` -> `/foo`), `handleNextDataRequest`
won't handle that request since it's no longer a data request.

It's strange to me that `handleNextDataRequest` and
`middleware_next_data` are doing similar path normalization in
completely different ways, but that was a deeper rabbit hole and simply
removing the normalization logic in `resolveRoutes` causes other
problems.

### How
Since data requests that flow through this middleware matcher logic
aren't going to be handled by `handleNextDataRequest`, I've updated
`middleware_next_data` to perform the logic of attaching the locale
information to the query. Initially I was going to do this for anything
that calls `normalizeLocalePath` but it seems like other branches of
`resolveRoutes` do it in the matcher function directly.

Fixes #54217
Closes NDX-116
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Aug 31, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Reviewers

@ijjk ijjk ijjk approved these changes

Assignees
No one assigned
Labels
created-by: Next.js team PRs by the Next.js team. locked tests type: next
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Server side locale always default in dynamic routes when a middleware is present
2 participants
@ztanner @ijjk