-
Notifications
You must be signed in to change notification settings - Fork 673
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
Fixed routes with same paths but different methods from being overwritten on Windows #465
Conversation
This reverts commit fd42fd4.
🦋 Changeset detectedLatest commit: 32d9fa0 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
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 |
Thanks for identifying this problem @Mexican-Man - and for the fix. Please can you add the following test to packages/wrangler/pages/functions/filepath-routing.test.ts in this PR so that we can ensure we don't regress. Note that I have wrapped the current tests in a new import { writeFileSync } from "node:fs";
import { runInTempDir } from "../../src/__tests__/helpers/run-in-tmp";
import { toUrlPath } from "../../src/paths";
import { compareRoutes, generateConfigFromFileTree } from "./filepath-routing";
import type { UrlPath } from "../../src/paths";
import type { HTTPMethod, RouteConfig } from "./routes";
describe("filepath-routing", () => {
describe("compareRoutes()", () => { ... });
describe("generateConfigFromFileTree", () => {
runInTempDir();
it("should generate a route entry for each file in the tree", async () => {
writeFileSync(
"foo.ts",
`
export function onRequestGet() {}
export function onRequestPost() {}
`
);
writeFileSync(
"bar.ts",
`
export function onRequestPut() {}
export function onRequestDelete() {}
`
);
const entries = await generateConfigFromFileTree({
baseDir: ".",
baseURL: "/base" as UrlPath,
});
expect(entries).toEqual({
routes: [
{
method: "PUT",
module: ["bar.ts:onRequestPut"],
routePath: "/base/bar",
},
{
method: "DELETE",
module: ["bar.ts:onRequestDelete"],
routePath: "/base/bar",
},
{
method: "GET",
module: ["foo.ts:onRequestGet"],
routePath: "/base/foo",
},
{
method: "POST",
module: ["foo.ts:onRequestPost"],
routePath: "/base/foo",
},
],
});
});
});
});
... |
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.
Approval from me once the test is in place.
@petebacondarwin I added your block, lmk if that fits what you were asking for. |
I updated the changeset and commit messages, and merged via 91d8994. |
See #490 for a detailed description of the problem this solves. Previously, we had `ws`'s automatic `Sec-WebSocket-Protocol` handling enabled, in addition to adding the header ourselves. This lead to duplicate sub-protocols in the WebSocket handshake response which is a protocol error. Workers require users to include this header themselves in WebSocket `Response`s, so ignoring this key outright when copying headers would be incorrect. Instead, we just disable `ws`'s automatic handling. Funnily enough, we had exactly the same issue in Miniflare 2 too (#179), and fixed it in 34cc73a. Looks like the fix didn't make it into Miniflare 3 though. :( This PR also fixes an issue where `1006` closures were not propagated correctly. This is an issue in Miniflare 2 too (#465), so we should back-port this. Supersedes #490
See #490 for a detailed description of the problem this solves. Previously, we had `ws`'s automatic `Sec-WebSocket-Protocol` handling enabled, in addition to adding the header ourselves. This lead to duplicate sub-protocols in the WebSocket handshake response which is a protocol error. Workers require users to include this header themselves in WebSocket `Response`s, so ignoring this key outright when copying headers would be incorrect. Instead, we just disable `ws`'s automatic handling. Funnily enough, we had exactly the same issue in Miniflare 2 too (#179), and fixed it in 34cc73a. Looks like the fix didn't make it into Miniflare 3 though. :( This PR also fixes an issue where `1006` closures were not propagated correctly. This is an issue in Miniflare 2 too (#465), so we should back-port this. Supersedes #490
See #490 for a detailed description of the problem this solves. Previously, we had `ws`'s automatic `Sec-WebSocket-Protocol` handling enabled, in addition to adding the header ourselves. This lead to duplicate sub-protocols in the WebSocket handshake response which is a protocol error. Workers require users to include this header themselves in WebSocket `Response`s, so ignoring this key outright when copying headers would be incorrect. Instead, we just disable `ws`'s automatic handling. Funnily enough, we had exactly the same issue in Miniflare 2 too (#179), and fixed it in 34cc73a. Looks like the fix didn't make it into Miniflare 3 though. :( This PR also fixes an issue where `1006` closures were not propagated correctly. This is an issue in Miniflare 2 too (#465), so we should back-port this. Supersedes #490
See #490 for a detailed description of the problem this solves. Previously, we had `ws`'s automatic `Sec-WebSocket-Protocol` handling enabled, in addition to adding the header ourselves. This lead to duplicate sub-protocols in the WebSocket handshake response which is a protocol error. Workers require users to include this header themselves in WebSocket `Response`s, so ignoring this key outright when copying headers would be incorrect. Instead, we just disable `ws`'s automatic handling. Funnily enough, we had exactly the same issue in Miniflare 2 too (#179), and fixed it in 34cc73a. Looks like the fix didn't make it into Miniflare 3 though. :( This PR also fixes an issue where `1006` closures were not propagated correctly. This is an issue in Miniflare 2 too (#465), so we should back-port this. Supersedes #490
This issue doesn't seem like it would be exclusive to Windows, but it made it into the latest release, so maybe it is. This PR works for me on Windows; can someone confirm it doesn't create duplicate paths on other OSes?