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

Fixed routes with same paths but different methods from being overwritten on Windows #465

Closed
wants to merge 9 commits into from

Conversation

colecrouter
Copy link
Contributor

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?

@changeset-bot
Copy link

changeset-bot bot commented Feb 15, 2022

🦋 Changeset detected

Latest commit: 32d9fa0

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

This PR includes changesets to release 1 package
Name Type
wrangler 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

@petebacondarwin
Copy link
Contributor

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 describe("filepath-routing") block.

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",
          },
        ],
      });
    });
  });
});

...

Copy link
Contributor

@petebacondarwin petebacondarwin left a 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.

@colecrouter
Copy link
Contributor Author

@petebacondarwin I added your block, lmk if that fits what you were asking for.

@petebacondarwin
Copy link
Contributor

I updated the changeset and commit messages, and merged via 91d8994.

@colecrouter colecrouter deleted the windows-fix branch February 18, 2022 20:47
mrbbot added a commit that referenced this pull request Oct 31, 2023
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
mrbbot added a commit that referenced this pull request Nov 1, 2023
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
mrbbot added a commit that referenced this pull request Nov 1, 2023
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
mrbbot added a commit that referenced this pull request Nov 1, 2023
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
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.

2 participants