Just send an HTTP request?

HHello, I’m Allie!Just send an HTTP request?

B

bret_pat•4/14/23, 6:03 AM

In that scenario, I would be responsible for creating my own means of authenticating the request.

B

bret_pat•4/14/23, 6:04 AM

But gotcha. I guess I was just wondering if there was a client library of some sort or not

Bbret_pat But gotcha. I guess I was just wondering if there was a client library of some s...

H

Hello, I’m Allie!OP•4/14/23, 6:05 AM

Not really, because any HTTP(S) request hitting a route covered by a Worker will run said Worker

H

Hello, I’m Allie!OP•4/14/23, 6:06 AM

There isn’t really anything there for the library to do

H

Hello, I’m Allie!OP•4/14/23, 6:06 AM

At least not with just a regular Worker

H

Hello, I’m Allie!OP•4/14/23, 6:07 AM

If you are running a GraphQL server on Workers, then there are a few libs to choose from there

A

airplantlifestyle•4/14/23, 6:17 AM

Hey folks, here's something that kept me up all night: I'm making a request to a db running on my server from within a worker. Running it locally works fine, but fails once it's deployed. I've been looking at the access logs on the server and the requests coming from the deployed worker seem off:
(worker on CF):

"GET /api/health HTTP/1.1" 404 19 "-" "-" 331 "-" "-" 0ms

"GET /api/health HTTP/1.1" 404 19 "-" "-" 331 "-" "-" 0ms

"GET /api/health HTTP/1.1" 404 19 "-" "-" 331 "-" "-" 0ms

"GET /api/health HTTP/1.1" 404 19 "-" "-" 331 "-" "-" 0ms
(worker running locally):

"GET /api/health HTTP/1.1" 200 41 "-" "-" 355 "pb1@docker" "http://172.24.0.5:8090" 1ms

"GET /api/health HTTP/1.1" 200 41 "-" "-" 355 "pb1@docker" "http://172.24.0.5:8090" 1ms

"GET /api/health HTTP/1.1" 200 41 "-" "-" 355 "pb1@docker" "http://172.24.0.5:8090" 1ms

"GET /api/health HTTP/1.1" 200 41 "-" "-" 355 "pb1@docker" "http://172.24.0.5:8090" 1ms

I notice that all the requests initiated from the deployed worker (even those with a body etc) all have only

19 bytes

19 bytes

19 bytes

19 bytes request size. It's a long shot, but what are your thoughts on that?

K

kian•4/14/23, 6:20 AM

Are you fetching an IP and/or on a non-standard port?

K

kian•4/14/23, 6:20 AM

If not, would need to see what the

fetch

fetch

code looks like

A

airplantlifestyle•4/14/23, 6:25 AM

Just your vanilla fetch:

const x = await fetch("https://db-dev.textmait.se/api/health");
console.log("Health", x.status);

const x = await fetch("https://db-dev.textmait.se/api/health");
console.log("Health", x.status);

const x = await fetch("https://db-dev.textmait.se/api/health");
console.log("Health", x.status);

const x = await fetch("https://db-dev.textmait.se/api/health");
console.log("Health", x.status);

A

airplantlifestyle•4/14/23, 6:25 AM

I already had the thought that it could have something to do with maybe certificates, but I guess then the request would fail in a different way?

A

airplantlifestyle•4/14/23, 6:28 AM

The thing that throws me off is that my reverse proxy (traefik) is the one returning the 404, it doesn't seem to be able to route it to the right docker container. So it's either an issue with the rev. proxy (traefik), or it's an issue with the request itself (cloudflare)

A

airplantlifestyle•4/14/23, 6:36 AM

Okay, just deployed a minimal example, and here the requests are fine (result and server logs). Must be something with the deployment config of the other worker.

A

airplantlifestyle•4/14/23, 6:40 AM

Update: It's a Cloudflare issue with custom domains. As soon as I add

route = { pattern = "api2.textmait.se", custom_domain = true, zone_id = "xxx" }

route = { pattern = "api2.textmait.se", custom_domain = true, zone_id = "xxx" }

route = { pattern = "api2.textmait.se", custom_domain = true, zone_id = "xxx" }

route = { pattern = "api2.textmait.se", custom_domain = true, zone_id = "xxx" } to my wrangler config, the requests fail. Any pointers to how my config is wrong?

K

kian•4/14/23, 6:42 AM

Is the Worker you're fetching from also on

textmait.se?

textmait.se?

textmait.se?

textmait.se?

K

kian•4/14/23, 6:42 AM

Same-zone subrequests are, uh, annoying

A

airplantlifestyle•4/14/23, 6:43 AM

Yup,

db-dev.textmait.se

db-dev.textmait.se

db-dev.textmait.se

db-dev.textmait.se is an A record pointing to my server,

api2.textmait.se

api2.textmait.se

api2.textmait.se

api2.textmait.se is managed by CF to point to the worker.

K

kian•4/14/23, 6:43 AM

Add

# https://github.com/cloudflare/workers-sdk/issues/2659
compatibility_flags = ["no_minimal_subrequests"]

# https://github.com/cloudflare/workers-sdk/issues/2659
compatibility_flags = ["no_minimal_subrequests"]

# https://github.com/cloudflare/workers-sdk/issues/2659
compatibility_flags = ["no_minimal_subrequests"]

# https://github.com/cloudflare/workers-sdk/issues/2659
compatibility_flags = ["no_minimal_subrequests"]

to your wrangler.toml

K

kian•4/14/23, 6:44 AM

you can track that issue to know when you can remove the compatibility flag

A

airplantlifestyle•4/14/23, 6:47 AM

Thank you! What exactly does this do? Because I'm not seeing any changes after deploying with it

K

kian•4/14/23, 6:47 AM

No idea - it's just what the Workers team recommend in that linked issue which supposedly fixes the same-zone subrequests

A

airplantlifestyle•4/14/23, 6:50 AM

Huh, okay. Tbh, never heard about same-zone subrequests until now, so I'll keep that in mind. I've at least now have our service back and running by using the .workers.dev domain, so thank you very much for pointing me into the right direction!

K

kian•4/14/23, 6:50 AM

Historically, a Worker on

foo.com

foo.com

foo.com

foo.com has never been able to fetch anything else on

foo.com

foo.com

foo.com

foo.com

K

kian•4/14/23, 6:50 AM

Using a custom domain (rather than a route) allowed it to fetch other things on

foo.com

foo.com

foo.com

foo.com

K

kian•4/14/23, 6:50 AM

but then

minimal_subrequests

minimal_subrequests

minimal_subrequests

minimal_subrequests (default as of

2022-04-05

2022-04-05

2022-04-05

2022-04-05) broke that

A

airplantlifestyle•4/14/23, 6:51 AM

Wow that's fascinating. I think I wouldn't have been able to figure that out by myself

A

airplantlifestyle•4/14/23, 6:51 AM

Worst case I gotta buy a second domain for the api

K

kian•4/14/23, 6:51 AM

It really should just work - comment on https://github.com/cloudflare/workers-sdk/issues/2659 that it's still broken for you and the team might have other suggestions

K

kian•4/14/23, 6:52 AM

That issue is more for Worker <-> Worker so there might be another bug for your Worker <-> Proxied Origin scenario

A

airplantlifestyle•4/14/23, 6:54 AM

Thank you, I'll do that!

P

plutoniumm•4/14/23, 5:45 PM

hey so idk if this is the right place for it please redirect me to the appropriate person if needed. I noticed the WASM Runtime is public under the

workerd

workerd

workerd

workerd package on NPM. I happen to hold the

workered

workered

workered

workered (with the 'e') package name but its not doing much and I don't need it. So I can release it if Cloudflare can put that to better use?

P

plutoniumm•4/14/23, 5:46 PM

Asking so that if you need it and I do it on the wrong time someone else would probably take it up lol

K

kian•4/14/23, 5:51 PM

Cloudflare doesn’t hold a trademark for workerd but I can see how that package name could be used maliciously for typos - cc @veerooo who can get the message to the right people

J

James•4/14/23, 6:34 PM

Functionally that code will work, but you won't really get the benefit of cache when you're combining scheduled workers + real traffic.

cache

cache

cache

cache is datacenter specific, and scheduled workers run in a subset of datacenters, so if you get traffic in a datacenter that your schedule didn't run in, it won't have a cache. And if that only runs once per hour for example, it's only cached in 1 location.

Your better option here would probably be to store the info to KV on that schedule instead - that provides much more of a guarantee, and will be quick to retrieve.

Ppaninizer Hi all. I have a question. So if I were to run Node.js with Express.js to route,...

C

Cyb3r-Jak3•4/14/23, 9:52 PM

You can't run express.js on workers. Workers uses the V8 run time not Node JS

Ppaninizer Would you suggest any other free hosting for what I have? If not I'll just have ...

C

Cyb3r-Jak3•4/14/23, 9:58 PM

railway or fly.io are going to be your best bets

Similar Threads

Similar Threads

Similar Threads