Skip to content
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

refactor: internalEvent.url is a full URL #752

Merged
merged 7 commits into from
Feb 26, 2025
Merged

refactor: internalEvent.url is a full URL #752

merged 7 commits into from
Feb 26, 2025

Conversation

vicb
Copy link
Contributor

@vicb vicb commented Feb 25, 2025

fixes #719

edit: One thing I need to check is the base path, we should probably add it when constructing URLs (i.e. 404, 500)

@conico974 could you please review and maybe run the aws integration tests when this looks ok?
cf tests are green with this PR.
Thanks!

Copy link

changeset-bot bot commented Feb 25, 2025

🦋 Changeset detected

Latest commit: 9ffa41a

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 3 packages
Name Type
@opennextjs/aws Patch
app-pages-router Patch
app-router Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

Copy link

pkg-pr-new bot commented Feb 25, 2025

Open in Stackblitz

pnpm add https://pkg.pr.new/@opennextjs/aws@752

commit: 9ffa41a

Copy link
Contributor

github-actions bot commented Feb 25, 2025

Coverage Report

Status Category Percentage Covered / Total
🔵 Lines 24.19% 2012 / 8316
🔵 Statements 24.19% 2012 / 8316
🔵 Functions 51.78% 116 / 224
🔵 Branches 71.82% 497 / 692
File Coverage
File Stmts Branches Functions Lines Uncovered Lines
Changed Files
packages/open-next/src/adapters/edge-adapter.ts 0% 0% 0% 0% 1-75
packages/open-next/src/adapters/middleware.ts 0% 0% 0% 0% 1-120
packages/open-next/src/core/requestHandler.ts 0% 0% 0% 0% 1-265
packages/open-next/src/core/routingHandler.ts 0% 0% 0% 0% 1-227
packages/open-next/src/core/routing/matcher.ts 77.68% 74.15% 91.66% 77.68% 37-39, 48-52, 57-59, 62, 101, 103, 106, 109, 119-120, 162-164, 275-277, 279-292, 311-312, 377-416
packages/open-next/src/core/routing/middleware.ts 96.49% 85.18% 50% 96.49% 34-37, 113
packages/open-next/src/core/routing/util.ts 87.15% 88.76% 90% 87.15% 87-90, 223-224, 294-296, 374-397
packages/open-next/src/overrides/converters/aws-apigw-v1.ts 96.87% 82.6% 100% 96.87% 94-96
packages/open-next/src/overrides/converters/aws-apigw-v2.ts 91.45% 83.33% 100% 91.45% 45-46, 50-54, 114-116
packages/open-next/src/overrides/converters/aws-cloudfront.ts 78.45% 80.76% 100% 78.45% 110-113, 158-198
packages/open-next/src/overrides/converters/edge.ts 0% 0% 0% 0% 1-102
packages/open-next/src/overrides/converters/node.ts 92.3% 78.57% 66.66% 92.3% 52-55
packages/open-next/src/overrides/converters/utils.ts 100% 100% 100% 100%
packages/open-next/src/overrides/wrappers/cloudflare-node.ts 0% 0% 0% 0% 1-85
packages/open-next/src/types/open-next.ts 0% 0% 0% 0%
Generated in workflow #1011 for commit 9ffa41a by the Vitest Coverage Report Action

@vicb vicb requested a review from conico974 February 25, 2025 10:34
Copy link
Contributor

@conico974 conico974 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All internal redirect are failing in e2e because of the incorrect url created.

One thing I need to check is the base path, we should probably add it when constructing URLs (i.e. 404, 500)

Yeah good point, we should probably create a helper functions for these cases

return {
type: "core",
method: httpMethod,
rawPath: path,
url: path + normalizeAPIGatewayProxyEventQueryParams(event),
url: `https://${headers.host ?? "on"}${path}${normalizeAPIGatewayProxyEventQueryParams(event)}`,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For all aws converters, the host will not be correct here.
The correct host is in the x-forwarded-host header, we apply it but only after the converter has already run :

if (initialHeaders["x-forwarded-host"]) {
initialHeaders.host = initialHeaders["x-forwarded-host"];
}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok I'll apply the change in aws converters.
Could the code in request handler (your link) be deleted then?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Honestly i'm not sure how to handle this one properly. We need the headers to be updated, but only if there is a x-forwarded-host

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could be done in the converter as it is aws specific, no?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not entirely, this is kind of a standard https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-Host.
And this will likely cause trouble when used with the node converter and wrapper as well.
Maybe a better solution would be to modify the url in the request handler as well. If we have a x-forwarded-host we change both the host header and the url to use this header.
We may have to move this to the routing handler though (in case of an external middleware)

url: `${rewrittenUrl}${convertToQueryString(finalQuery)}`,
url: new URL(
`${rewrittenUrl}${convertToQueryString(finalQuery)}`,
new URL(event.url),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here it fails in e2e because event.url is incorrect.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you know what test fails?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

test("Missing cookies", async ({ page }) => {

test("Has cookies", async ({ page }) => {

test("Has cookies with value", async ({ page }) => {

And these 2
test("Redirect with default locale support", async ({ page }) => {
await page.goto("/redirect-with-locale/");
await page.waitForURL("/ssr/");
const el = page.getByText("SSR");
await expect(el).toBeVisible();
});
test("Redirect with locale support", async ({ page }) => {
await page.goto("/nl/redirect-with-locale/");
await page.waitForURL("/nl/ssr/");
const el = page.getByText("SSR");
await expect(el).toBeVisible();
});

@@ -62,7 +62,7 @@ async function convertFromAPIGatewayProxyEvent(
type: "core",
method: httpMethod,
rawPath: path,
url: `https://${headers.host ?? "on"}${path}${normalizeAPIGatewayProxyEventQueryParams(event)}`,
url: `https://${headers["x-forwarded-host"] ?? "on"}${path}${normalizeAPIGatewayProxyEventQueryParams(event)}`,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not 100% correct either, we could create an helper function that would retrieve the host from the headers.
If this header is not set (which can be the case), we should fallback to the host header

Copy link
Contributor Author

@vicb vicb Feb 25, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you mean an helper to headers["x-forwarded-host"] ?? headers.on ?? "on" ?
For all aws converters?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That was my original idea, but i think there is a better solution (#752 (comment)). In the converters we keep headers.host ?? "on", but in the routing handler if we have a x-forwarded-host header, we change both the host header and the internalEvent.url

@vicb
Copy link
Contributor Author

vicb commented Feb 25, 2025

I have pushed some commits to integrate the feedback.

@conico974 Could you please run the test in debug mode and report the rewrittenUrl is they are still failing?

debug("rewrittenUrl", { rewrittenUrl, finalQuery, isUsingParams });

Thanks!

Copy link
Contributor

@conico974 conico974 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've run the e2e test and everything is working as expected.
LGTM Thanks

@vicb
Copy link
Contributor Author

vicb commented Feb 25, 2025

Thanks a lot @conico974, I will double check the basePath thing before merging.

@vicb
Copy link
Contributor Author

vicb commented Feb 26, 2025

I tested using a basePath on cloudflare and it works the same as with next dev, merging

@vicb vicb merged commit e48951f into main Feb 26, 2025
3 checks passed
@vicb vicb deleted the url branch February 26, 2025 08:34
@github-actions github-actions bot mentioned this pull request Feb 24, 2025
This was referenced Feb 26, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Make event.url consistent across platforms (URL vs path)
2 participants