You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When returning NextResponse.rewrite from middleware, next/server determines whether to proxy the request by checking if the parsed rewrite URL has a protocol. When running on localhost this will be false, so it will handle the rewrite as expected. However if running with a hostname, such as if using mycomputername.local:3000, using any other value for localhost (such as 127.0.0.1), or running a live server, then the parsed URL will have a protocol, so the server will attempt to proxy to the address. This will result in either an ssl error or a proxy loop.
I am happy to submit a PR to fix this. It can be fixed by also checking if the rewrite host matches the request host.
Expected Behavior
Server does not attempt to proxy local rewrites, even when running with a hostname.
This changes the check for whether a rewrite is internal or if it should be proxied. Currently it checks if `protocol` is unset, which is only the case for relative URLs or localhost. This means that requests where there is a hostname set, or if localhost is specified in another way such as `127.0.0.1`, then it will be proxied, which potentially causes a proxy loop or ssl error. This PR changes the test so that it also checks if the hosts match, and only proxies if they are different.
Fixes#31179
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
This issue has been automatically locked due to no recent activity. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.
vercel
locked as resolved and limited conversation to collaborators
Jan 27, 2022
natew
pushed a commit
to natew/next.js
that referenced
this issue
Feb 16, 2022
This changes the check for whether a rewrite is internal or if it should be proxied. Currently it checks if `protocol` is unset, which is only the case for relative URLs or localhost. This means that requests where there is a hostname set, or if localhost is specified in another way such as `127.0.0.1`, then it will be proxied, which potentially causes a proxy loop or ssl error. This PR changes the test so that it also checks if the hosts match, and only proxies if they are different.
Fixesvercel#31179
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
bugIssue was opened via the bug report template.MiddlewareRelated to Next.js Middleware.
What version of Next.js are you using?
12.0.4-canary.0
What version of Node.js are you using?
16.11.0
What browser are you using?
Firefox
What operating system are you using?
macOS
How are you deploying your application?
next start
Describe the Bug
When returning
NextResponse.rewrite
from middleware, next/server determines whether to proxy the request by checking if the parsed rewrite URL has a protocol. When running on localhost this will be false, so it will handle the rewrite as expected. However if running with a hostname, such as if usingmycomputername.local:3000
, using any other value for localhost (such as127.0.0.1
), or running a live server, then the parsed URL will have a protocol, so the server will attempt to proxy to the address. This will result in either an ssl error or a proxy loop.I am happy to submit a PR to fix this. It can be fixed by also checking if the rewrite host matches the request host.
Expected Behavior
Server does not attempt to proxy local rewrites, even when running with a hostname.
To Reproduce
localtest.me
(which resolves to localhost)The text was updated successfully, but these errors were encountered: