fix(next/routing): compare i18n domains by hostname when redirecting - #97005
Draft
yogesh968 wants to merge 1 commit into
Draft
fix(next/routing): compare i18n domains by hostname when redirecting#97005yogesh968 wants to merge 1 commit into
yogesh968 wants to merge 1 commit into
Conversation
The locale redirect compared the raw `domains[].domain` against the request hostname. `detectDomainLocale` strips the port and lowercases before matching, so a domain configured as `example.de:3000` never compared equal to the `example.de` we are already serving. That took the cross-domain branch and rebuilt the URL from the config, which replaced the request scheme: a request to http://example.de:3000/ was redirected to https://example.de:3000/fr/ instead of staying on http. Reuse the same normalization for the comparison.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What?
A locale redirect for an i18n domain configured with a port sent the user to the wrong scheme. A request to
http://example.de:3000/withdomains: [{ domain: 'example.de:3000', defaultLocale: 'de', locales: ['de', 'fr'] }]andAccept-Language: frredirected tohttps://example.de:3000/fr/instead of staying onhttp.Why?
Two places compared the configured domain against the request hostname, but only one of them normalized:
detectDomainLocalestrips the port and lowercases before matching, so it correctly resolvedexample.de:3000for theexample.dehost we were already serving.resolveRoutescompared the rawtargetDomain.domainagainsthostname—'example.de:3000' !== 'example.de'— so it concluded we were on a different domain.That took the cross-domain branch, which rebuilds the URL from the config, and the rebuilt URL derives its scheme from
targetDomain.httprather than the incoming request. Hence the silenthttp→httpsswitch on a same-origin redirect.How?
Extract the normalization
detectDomainLocalewas already doing inline into an exportedgetDomainHostname(domain)ini18n.ts(strip port, lowercase), and use it inresolveRoutesfor the comparison. Both call sites now agree on what "same domain" means, so the port-carrying config takes the same-origin branch and keeps the request's scheme, host and port.The comparison result is hoisted into
isTargetDomainCurrentand reused by both branches, which also removes the redundanttargetDomain &&re-check in the second condition.Test added in
packages/next-routing/src/__tests__/i18n-resolve-routes.test.tsasserting the redirect keepsorigin === 'http://example.de:3000'and gains the/fr/prefix.