Wrangler: `wrangler dev` in 11.0 is non-functional when there are deployed workers with non-specific routes

[TehShrike]

🐛 Bug Report

I have a worker deployed with a very broad/non-specific route, *example.com/*. It handles some generic redirect behavior.

I have other workers with more specific routes, e.g. https://subdomain.example.com/path/*.

This works fine, thanks to Cloudflare Workers' route matching behavior where the most specific routes are matched first.

However, as of wrangler 11.0, I am unable to test my workers with more specific routes. I run wrangler dev and everything starts up fine, but when I make GET requests to http://127.0.0.1/path/anything, those requests are handled by the *example.com/* worker in production.

This is a bug. At the very least, the route matching rules should be applied, using the route/routes in my wrangler.toml file.

This is concerning. It makes me very nervous that my HTTP requests to 127.0.0.1 could be handled by production workers. This implies that if I'm POSTing to localhost with a valid Authorization header, I could be causing side effects in production.

I do not want/expect requests to localhost to be proxied to unrelated deployed production code.

Environment

• operating system: macOS
• output of rustc -V: -bash: rustc: command not found
• output of node -v: v14.8.0
• output of npx wrangler -V: 👷 ✨ wrangler 1.11.0
• contents of wrangler.toml

Steps to reproduce

What did you expect to see?

What did you see instead?

[caass]

I think this is related to an issue I'm getting, so I'll comment here to avoid opening a duplicate issue.

Steps to reproduce:

1. Create a new wrangler project with wrangler generate example https://github.com/cloudflare/worker-template
2. cd in, populate account_id in wrangler.toml
3. Run wrangler dev, observe that it works
4. Add a route to wrangler.toml that includes a wildcard (e.g. route = somesite.com/*)
5. Add the zone_id for that route, and set workers_dev to false
6. try wrangler dev again
7. Get some output similar to this:

Error: error sending request for url (https://somesite.com/cdn-cgi/workers/preview/?s0=ARPdR5deFqRukgETnkKjn5kSzdo_snRbbMwyeEOIOFMYvs1rH2YrzgvNFKyZQ15Gs6UCiPoylQhuLz_HH692NucZ9_lTDjFeLW5zVueo3fVZQIDl7LgnfW-jQlmD12VveT96NH_KMGy0z6SRtZZmcwy7rWDJs3HaWQqriG6mEyN10p7fyXIsMln87fZM6zKOo-oClrM-iKoq9iCBDVO06NG535432I0gxndTxmWxTY-5NI8MOEgUW5DVur8AGJ-xBSrMoq7JYCKEUHVM2Rww9I3rgOvRWy0PfS4gTEFX7RJv): error trying to connect: dns error: failed to lookup address information: nodename nor servname provided, or not known

This happens whether the route or routes key is specified.

Expected Behavior

I suppose it should look something like this:

• Worker starts up
• For subdomain pattern matching (e.g. .somesite.com), i feel like it's the responsibility of the user to use something like dnsmasq to forward arbitrary domains to localhost or whatever IP workers dev is running on. I *think the request intercepted will have that domain attached to it so the worker can run its "should i execute" logic on it
• For path matching (e.g. somesite.com/*), it's already possible to route requests to (for example) 127.0.0.1:8787/foo, and in fact without a route specified this is the default behavior -- all requests to the ip:port the worker is running on are intercepted, regardless of the path.

I mean basically the expected behavior is what already happens when no route (workers_dev=true) is specified. If I were to speculate, I think the "frontend" for this already works -- workers can already spin up and catch requests to any path on their port, and while I haven't tried it, I suspect the dnsmasq technique works as well. I think it has to do more with the "backend" part, where the worker is actually created based on a route.

[TehShrike]

@caass for thoroughnesses sake, what is your expected behavior after step 4, and what are you seeing instead of that?

[caass]

@caass for thoroughnesses sake, what is your expected behavior after step 4, and what are you seeing instead of that?

@TehShrike I edited my comment to put the expected behavior, as well as what actually happens :)

[ashleymichal]

note: status - needs repro indicates that we'd like a member of our team to reproduce; thank you for the detailed report!

[emesterhazy]

Thanks for posting this @TehShrike - I have the same issue as you. I can't test workers that match on subdomains with dev because all requests to localhost are forwarded to the production server for the bare domain.