req.url protocol and host are incorrect when used behind AWS ALB with SSL termination

[andycansdale]

Verify canary release

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

Provide environment information

Operating System:
      Platform: darwin
      Arch: x64
      Version: Darwin Kernel Version 22.5.0: Thu Jun  8 22:22:22 PDT 2023; root:xnu-8796.121.3~7/RELEASE_X86_64
    Binaries:
      Node: 20.2.0
      npm: 9.6.6
      Yarn: 1.22.19
      pnpm: 8.6.1
    Relevant Packages:
      next: 13.4.12
      eslint-config-next: 13.4.9
      react: 18.2.0
      react-dom: 18.2.0
      typescript: 4.9.5
    Next.js Config:
      output: standalone

Which area(s) of Next.js are affected? (leave empty if unsure)

No response

Link to the code that reproduces this issue or a replay of the bug

None

To Reproduce

You would need to replicate the infrastructure as mentioned in the bug report. Or perhaps another infrastructure with SSL termination before reaching the NextJS app, but where the original request was made via https.

Describe the Bug

We deploy NextJS behind an AWS Application Load Balancer which terminates SSL. After upgrading from 13.4.12, the protocol and host value in our middleware is different.

Before
req.url: http://ip-10-x-x-x.ec2.internal:5000/dashboard
req.NextUrl.host: ip-10-x-x-x.ec2.internal:5000
req.NextUrl.protocol: http

After
req.url https://10.x.x.x:5000/dashboard
req.NextUrl.host 10.x.x.x:5000
req.NextUrl.protocol https

Not only has the hostname changed to an IP address, the protocol is now shown as https when in fact the request from our ALB uses http.

I believe the issue started with 13.4.13-canary.0, but I can't confirm as that release also broke our healthcheck endpoint! I can confirm it is still an issue in the latest canary release at the time of writing this.

The req.url and req.nextUrl values are logged to the console at the very beggining of our middleware before any other changes are made.

Expected Behavior

Expected behaviour is for the protocol to be correct for req.url in middleware.

Which browser are you using? (if relevant)

No response

How are you deploying your application? (if relevant)

AWS, ALB + ECS

[andycansdale]

By the way, the issue that this causes is that it completely breaks our NextResponse rewrites which now have the wrong protocol & host values after updating just the path from the original req.url.

[crathor]

13.4.13 works for me but as soon as I upgrade to 13.4.15 or higher it fails the same as above

[phev8]

Might we have missed some config where this behaviour can be changed?

Just wondering, because this issue makes the newer releases of NextJS unusable in this setup, but there are not many responses (either by the dev team or others). Maybe not so many people use NextJS with "self-hosting" on a cluster (e.g. AWS, GCP, Azure, OpenShift)... In our case, we had to downgrade NextJS and are stuck at the moment with an earlier release until this is fixed. (I refer to the other issue raised ca. a week ago as well)

(I love NextJS and huge respect to the team building it - just to clarify :-) )

[deflomu]

We face the same issue. This prevents us from updating to nextjs 13. We can also not set a hostname via env or config because our application servers multiple hostnames.

[andycansdale]

@deflomu I haven't tested in production yet, but this is supposed to be fixed by this PR #54813 which is available on the latest canary release. The PR by @DuCanhGH was closed in preference to the previous one. Let's hope it works because this blocked a lot of projects.

[florianmutter]

We face the same issue. This prevents us from updating to nextjs 13. We can also not set a hostname via env or config because our application servers multiple hostnames.

Works as expected for us with latest canary build.

[phev8]

For me, the issue seems to be still present in v13.5.1, when using my reproduction steps from here: #54450

[phev8]

Works as expected for us with latest canary build.

The changes from that PR were reverted in the next canary, weren't they?

[andycansdale]

We're running 13.5.1 with no issues now. Our middleware redirects have the correct protocol and host.

[github-actions]

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