-
-
Notifications
You must be signed in to change notification settings - Fork 253
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.
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
fix: Detect host and protocol for alternate links correctly when running behind a proxy #462
Conversation
@HHongSeungWoo is attempting to deploy a commit to the next-intl Team on Vercel. A member of the Team first needs to authorize it. |
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
I'm concerned about trusting the host of the header, but if there are multiple external addresses on the same server, I can't think of any other solution :( |
b0417e6
to
fa3bce6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you so much for proposing this fix @HHongSeungWoo!
It's definitely a good idea to use the external host for the alternate links, please see my inline comment for details.
Can you please also include tests that would have failed previously and will now pass after the fix?
Thank you so much! 🙌
Is this somehow related to this issue? |
This looks great! The only thing missing would be a regression test that helps to ensure that we keep this functionality in the future. Thanks also for linking to the Next.js issue, I'll keep an eye on that, but seems like it should be addressed on the Next.js side. |
I'm unsure about the necessary test cases. The request.url within the middleware is a string generated by Next.js. If a hostname is configured, it will be used; otherwise, localhost will be used. Upon reviewing the code, it appears that the option trustHostHeader, which is not currently utilized, generates the URL with the request's host when set to true. However, since this isn't documented, it seems to be an unused option. These changes are independent of external configurations or code modifications, so I can't think of any regression cases unless there are changes to the HTTP protocol itself. |
23ceb21
to
97653c0
Compare
…est` with `NextRequest` constructor to avoid unnecessary indirection
@HHongSeungWoo I've added a commit where the now fixed behavior is handled within a single test case. I also noticed that we should consider the protocol as well and fixed that accordingly. Thanks for noticing that we can use the Would you like to have a last look? From my opinion this is good to go! 👍 |
Thank you for making the necessary corrections. It looks better to me as well. :) |
Hello @amannn ! This looks great, but please would it be possible to push this fix to the beta branch as well? Currently im stuck with the bug on the beta-10 :-/ |
@CarbonC Yep, definitely! I've got another release on the main branch coming, then I'll rebase the RSC branch and publish a new beta! |
@CarbonC |
…ehind a proxy (`x-forwarded-host`, `x-forwarded-proto`) (amannn#462 by @HHongSeungWoo) --------- Co-authored-by: Jan Amann <[email protected]>
We are currently utilizing a reverse proxy in front of Next.js.
request.url
is returning an internal address instead of an external one.Consequently, the rewrite functionality is not behaving as expected, and the
alternatelink
header is inadvertently exposing the internal address.