After updating to v3.11.1 rewrite/redirects append a port to the URL

[pepijn-vanvlaanderen]

Description

The last change for internal redirecting appends a port to the URL. However in our setup at Railway.app this does a faulty redirect. When the middleware should rewrite / redirect, it takes a long time and eventually redirects to the correct URL but with the port number and that crashes.

Reverting to v3.11.0 works.

Verifications

• I've verified that the problem I'm experiencing isn't covered in the docs.
• I've searched for similar, existing issues on GitHub and Stack Overflow.
• I've compared my app to a working example to look for differences.

Reproduction description

Steps to reproduce:

1. Open reproduction
2. Wait about a minute or so
3. See error: the page does not work and is redirected to https://domain:3000/winkelwagen

Expected behaviour

A redirect to https://domain/winkelwagen showing a page.

[awkaiser-tr]

@pepijn-vanvlaanderen your suggestion of config to control what port is used may be the way to go, but it's also possible that the current logic is suboptimal. To troubleshoot further, what request headers are available to Next.js? Do you have values for any of the x-forwarded-* headers, e.g.

• x-forwarded-host
• x-forwarded-proto
• x-forwarded-port

... or a forwarded header?

[amannn]

@pepijn-vanvlaanderen Sorry for the inconvenience caused by this change!

But yes, as @awkaiser-tr has pointed out, it would be important to get details about the specific request headers your app receives. Based on that, we can add a failing test like @awkaiser-tr did in #979 and look into an appropriate fix.

I'd really like to avoid config as much as possible if we can, therefore the best option from my perspective would be to just do the right thing based on the information we have available.

Can you also share your domains config?

@awkaiser-tr Can you too share your domains config? Maybe we could also utilize a port that is potentially defined there for the detection.

[awkaiser-tr]

My domains config looks like:

{
  defaultLocale: 'de-DE',
  domain: getDomain('de-DE').host,
  locales: ['de-DE'],
},
{
  defaultLocale: 'en-CA',
  domain: getDomain('en-CA').host,
  locales: ['en-CA', 'fr-CA'],
},
{
  defaultLocale: 'en-GB',
  domain: getDomain('en-GB').host,
  locales: ['en-GB'],
},
// ... and so on ...

... where host is the locale domain for current Next.js environment, e.g.

• development @ de-yourcompany-dev.localhost
• production @ www.yourcompany.de

[awkaiser-tr]

@amannn are you suggesting an optional port property on the per-domain config?

Since most deployments will be reached via standard HTTP (80) / HTTPS (443) port, treating non-standard ports as outliers that require config makes sense and would probably result in fewer issues filed on this project.¹

However, if DomainConfig were to begin caring about port, it would also need to consider protocol:

{ // For sake of discussion ...
  defaultLocale: 'en-CA',
  domain: getDomain('en-CA').host, // `'www.yourcompany.ca'` || `'ca-yourcompany-dev.localhost'`
  locales: ['en-CA', 'fr-CA'],
  protocol: getDomain('en-CA').protocol, // `'https://'` || `'http://'`
  port: getDomain('en-CA').port, // `undefined` || `3000`
},

... where by default next-intl redirects use Next.js' request protocol and omit port, overridden by DomainConfig values first and proxy headers in absence of that config.

Footnotes

1. Do not many people test domain-based l10n during development on alternative ports like Next.js' default dev port 3000? 🤔 ↩

[amannn]

Yep, that's correct. We currently use the protocol and port of an incoming request to determine wether to add it to a domain that we're redirecting to.

I was wondering if the port could even be part of domain (e.g. domain: 'www.yourcompany.de:3000') to avoid introducing new properties, but I guess that would be somewhat of a stretch for the term "domain". A separate property like you're suggesting might be the most explicit option. EDIT: Seems like we've silently already supported this, so maybe this is the way to go and we should document it.

An explicit port in the domain config should also give users more flexibility, maybe one domain runs on a different port than another domain. I think this might be a reasonable path forward without having to rely on detecting a reverse proxy, which seemingly people have different configurations for.

What do you think?

[pepijn-vanvlaanderen]

Hi @amannn , hereby my domains config:

    localePrefix: 'as-needed',
    localeDetection: false,
    locales: ['nl'],
    defaultLocale: 'nl',
    pathnames: {
        ...,
        '/cart': {
            en: '/cart',
            nl: '/winkelwagen',
        },
        ...
    },
    domains: [
        {
            domain: `${process.env.DOMAIN_NL ?? 'localhost:3000'}`,
            defaultLocale: 'nl',
        },
    ],

As you can see, we currently only support 1 language as we are still waiting on translated content, but internally we use next-intl already to translate short texts.

@awkaiser-tr how does your getDomain look like? I was as well wondering for an easy ussage on local developing here.

[awkaiser-tr]

Local development w/ locale-based domains

@pepijn-vanvlaanderen the getDomain function returns { host, origin, pathname, port, protocol } by locale, with values determined by environment. You just need to associate some locale-specific domains with your loopback address, e.g. /etc/hosts:

127.0.0.1 ca-yourcompany-dev.localhost
127.0.0.1 de-yourcompany-dev.localhost
127.0.0.1 es-yourcompany-dev.localhost
127.0.0.1 fr-yourcompany-dev.localhost
127.0.0.1 it-yourcompany-dev.localhost
127.0.0.1 pt-yourcompany-dev.localhost
127.0.0.1 uk-yourcompany-dev.localhost
127.0.0.1 us-yourcompany-dev.localhost
127.0.0.1 yourcompany-dev.localhost

[awkaiser-tr]

@amannn: I was wondering if the port could even be part of domain (e.g. domain: 'www.yourcompany.de:3000') to avoid introducing new properties, but I guess that would be somewhat of a stretch for the term "domain".

Agreed, that would be overloading domain in a surprising way. 🙅🏻

A separate property like you're suggesting might be the most explicit option. EDIT: Seems like we've silently already supported this, so maybe this is the way to go and we should document it.

An explicit port in the domain config should also give users more flexibility, maybe one domain runs on a different port than another domain. I think this might be a reasonable path forward without having to rely on detecting a reverse proxy, which seemingly people have different configurations for.

What do you think?

Adding port to DomainConfig would be fine, so long as protocol (e.g. https://, http://) is also available. A secure or insecure web server can listen on any available port, and the protocol of an internal Next.js server could mismatch its public-facing reverse proxy, so we can't make assumptions about protocol with no way to override. Presumably this also means consideration of proxy-related headers would be removed? Leaving it up to the user, with sensible defaults in absence of DomainConfig values, does feel like the best choice. If they want to set config values based on incoming headers, they'd be free to do that.

[amannn]

@pepijn-vanvlaanderen Can you share which request headers your app receives in your Railway setup? Maybe you can add some logging in the middleware?

I did some research and it seems like Railway uses Envoy, which in turn should support x-forwarded-host and x-forwarded-port.

Supporting different ports for different domains as discussed above could be interesting, but for now, the easiest fix might be to apply ports correctly when running behind a reverse proxy. It would be helpful to learn if Railway is accidentally stripping important headers here of if the middleware logic of next-intl has a bug.

With the fix from @awkaiser-tr in #979 we now have this logic:

1. If a x-forwarded-host is present, we assume that the app runs behind a reverse proxy
2. If the app runs behind a reverse proxy, we apply x-forwarded-proto and x-forwarded-port to a domain we're potentially redirecting to. If these headers are absent, we default to request.nextUrl.protocol and no port.

It would be interesting to learn about the exact values of these request headers in your app to diagnose where the issue is. Can you share them? Thanks!

[pepijn-vanvlaanderen]

.

[awkaiser-tr]

@amannn funny enough, I just experienced the same bug RE: localized pathname redirects 💣

@pepijn-vanvlaanderen quick sanity check: I see you're reporting x-forwarded-port as 3000, but was that just for the https://yeahgummy-nl.webbers.dev:3000/winkelmand request? What is the value of the x-forwarded-* headers for the /cart requests?