`node:https.request` support

[fl0wo]

Describe the feature

Hi, just to make sure, is https.request implemented for cloudflare?

If not, do you think there an ETA for it? I'd love to help if possible.

Additional information

• [X] Would you be willing to help implement this feature?

### Tasks

[fl0wo]

Any update on this?

[keiwanmosaddegh]

I'm also interested in this. @fl0wo have you found any workaround in the meantime?

[vicb]

Hi, just to make sure, is https.request implemented for cloudflare?

confirmed that it is not.

Could you please expand on the use case?

[keiwanmosaddegh]

Hi, just to make sure, is https.request implemented for cloudflare?

confirmed that it is not.

Could you please expand on the use case?

I'm quite new to Cloudflare workers and all so there might be a clear solution for my issue, however I haven't been able to troubleshoot myself to something.

I'm building a Worker API that uses Firebase App Check for Auth. I'm getting the uenv not implemented error when using the App Check library. That's why I'm in need of it. Let me know if I can help by elaborating further. @vicb

[vicb]

As you probably already knows Workers use the workerd Runtime that does not implement all of the Node.js APIs.

However we are looking at supporting more and more of the Node libs.

There are a few things that can help here:

• cloudflare implementing the missing APIs
• unenv polyfilling the missing APIs
• libraries being updated to run on the edge by using Web APIs instead of the Node APIs

So what you can do here to help is:

• Create an issue on the firebase repo explaining that you want to run the code at the edge and asking for Web APIs support (i.e. fetch)
• Create a discussion on the workerd repo explaining what repo/version/API you would like to see supported - please link to this issue, the issue on the firebase repo and mention me there

And we'll get that working.

Thanks!

[pi0]

Ideally, i would love to have a polyfill based on wintercg web sockets proposal which workerd currently support (startTLS) — and it should enable a universal / spec compatible solution in the future.

Native workerd support would be cool but i think it is still viable to be discussed for unenv support :)

—-

I think we should also investigate firebase SDK issue separately, i guess it can be solved by making sure it leverages fetch for http calls (unless they really need TCP connect)

[fl0wo]

I'm also interested in this. @fl0wo have you found any workaround in the meantime?

I'm partially migrating from AWS to CF, at least for the resources it make sense to migrate from.

And in doing this hybrid architecture, I'm trying to pushing some messages from CF Worker, to SQS (directly invoking the AWS API) (using the aws-lite library https://aws-lite.org/services/sqs)

In doing so, I get the https.request not implemented error.

Workaround 1: Ask aws-lite to allow me to implement a custom fetch (one that is compatible on CF env) Denied: https://github.com/aws-lite/aws-lite/issues/171

Workaround 2: Implement an ApiGtw on AWS, that wraps SQS, and simply pushes messages to SQS with a basic API-Key authentication. And I'll invoke that api endpoint from Cloudflare...

[pi0]

(offtopic) @fl0wo have you tried aws4fetch as an alternative?

[vicb]

I can definitely recommend aws4fetch here:

• It was created by Michael Hart who works at cf
• It is used in @opennextjs/aws

[jasonbarry]

Relevant workerd discussion: https://github.com/cloudflare/workerd/discussions/3050

[fl0wo]

aws4fetch

I followed your suggestion, it worked perfectly thank you.

[wesbos]

https.request and/or xmlhttprequest support would be great. I suspect many of the issues people are hitting are when an upstream dependency uses axios which uses either of these. Ideally we would just use fetch, but it's not often possible and a dealbreaker for people using workers

Edit - looks like Axios did add a fetch adapter recently - so that will probably alleviate these issues quite a bit. https://www.npmjs.com/package/axios#-fetch-adapter

[vicb]

I guess cloudflare/workerd would be a good repo for that issue / discussion - there are probably existing ones

[xumx]

Any update or workaround to this? This breaks many packages and makes it unusable on cloudflare / nuxthub

Specifically I was depending on a package for twitter-api-v2

[CoolOppo]

Major problem, tons of stuff broken, please fix

[pi0]

For cloudflare users, this feature should be implemented in workerd (upstream tracker: https://github.com/cloudflare/workerd/issues/3820). You can check the native support coverage from here.

We might make a polyfill based on the new node:tls support, but I'm out of bandwidth right now also not sure if worth to invest time if it will be landing on workerd /cc @vicb @anonrig

[xumx]

We are unlikely to implement the node:https module directly in the runtime and will likely continue to rely on the unenv polyfills to bring these in. An implementation of node:https could likely fit on top of the built-in fetch implementation but it is also unlikely that we will ever fully support all of the TLS configuration options, lifecycle events, etc as our internal infrastructure uses an entirely different model than Node.js.

Originally posted by @jasnell in https://github.com/cloudflare/workerd/discussions/3050#discussioncomment-11152738

[bunnybones1]

I discovered this issue when migrating from pages to a worker, and the new vite/cloudflare plugin. What surprised me was that code that depended on https ran fine in pages. I thought pages was just an opinionated framework built on top of workers, but now I'm not so sure. Any idea why https worked in pages but not worker?

[Camusama]

Yes, I really need this feature

[reggieross]

Would love this feature

[homerjam]

Sorry, just saw this https://github.com/cloudflare/workerd/issues/3820#issuecomment-3197578467