Cloudflare workers support?

[Zombobot1]

This library cannot be used in cloudflare workers because it depends on XMLHttpRequest.
Moreover, if I send requests manually they fail with status code 525.

Code to reproduce

const deepLUrl = 'https://api-free.deepl.com/v2/translate'
const text = 'I like my cat'
const to = 'de'
const from = 'en'

const resp = await fetch(deepLUrl, {
  method: 'POST',
  headers: {
    'Content-Type': 'application/x-www-form-urlencoded',
    Authorization: `DeepL-Auth-Key ${env.DEEPL}`,
  },
  body: `text=${encodeURIComponent(text)}&target_lang=${to.toUpperCase()}&source_lang=${from.toUpperCase()}`,
})
if (!resp.ok) throw new Error(`DeepL error (${resp.status}) ` + resp.statusText) // throws in workers
const response = await resp.json()
response.translations[0].text // works in node

This problem is often mentioned in cloudflare community (example). According to cloudflare "This is typically caused by a configuration issue in the origin web server".

Is there any hope for a fix? Cloudflare workers become more and more popular nowadays.

[daniel-jones-deepl]

Hi @Zombobot1, thanks for creating the issue; we're looking into it and I'll update you when I have more information.

[tutankhamen-1]

I’d appreciate an update on this as well. Currently can’t use the API because of this.

[croshim]

Have the same issue, are there any updates?

[JanEbbing]

Hi, thanks for the report. I looked into this and I see 2 separate issues.

1. deepl-node cannot be used in cloudflare workers as they don't provide a full node environment

There is no good way we can support this - e.g. workers don't have access to any file system so we could not implement document translation at all, aside from all the basic node functionality we would need to migrate away from.

2. Making direct API requests from a cloudflare worker fails with HTTP Error 525 (SSL Handshake failed)

I looked into this for a while now - e.g. I checked our API with this SSL test and it looks correctly configured to me. If I had to guess, cloudflare workers don't seem to offer the right SSL ciphers by default (the ones they say they offer here would work), but I have no way to verify that - workers only expose the fetch API, which is HTTP-level, and you don't have access to e.g. the tls or https modules to verify anything.
In addition, I found many user reports about the same problem for many other APIs, which indicates the problem lies with cloudflare workers, not us:

• 1
• 2
• 3

So unfortunately it seems cloudflare workers are incompatible with both the client library and our API overall :(
Could you describe your use case to me? Maybe we can find a satisfying solution still.

[Zombobot1]

I have opened a corresponding issue in the cloudflare repo. They ask: "Is zone's SSL mode Full?"

[JanEbbing]

They mean this setting. As I'm just trying a worker (without a website), I don't think I can access that setting (at least I can't find SSL anywhere) - maybe for you that's different?

I asked internally as well - it seems our Ops team has been talking to cloudflare as well, but couldn't fix the problem. If I had to guess, there is no SSL ciphersuite that both servers support, we are looking into it.

[JanEbbing]

Hi, just to give a quick update here - for the API not being reachable at all from cloudflare workers (HTTP Error 525):
We have worked with CloudFlare and identified the issue, this is an issue in CloudFlare workers, and they are working on fixing it.

Just to reiterate, once this is fixed you can manually connect to the DeepL API from CloudFlare workers. As this library needs a full node environment, which is not present on CF workers, the library still won't support CF workers.
We are looking into options to avoid this restriction, in order to offer easier DeepL translations in other environments as well.

[Zombobot1]

Thank you. Is there an open issue to track? My issue in the worked repo is kind of stuck.

[Omarov3000]

@JanEbbing Is there a way to be notified when the deepl is accessible by cloudflare workers? I mean when the 525 error is fixed. We would like to start using it in our company. Perhaps this issue should be left open until then?

[JanEbbing]

I think the best way right now is to follow this ticket (which you seem to follow already).

For the issue, I will discuss with my team if we should have an issue-tracking repository on Github for the DeepL API. This repository is just for the NodeJS client library (but we get general API questions in all CL repos from time to time), so I think if we keep a tracking issue open it makes the most sense to put it there.

I will also ask internally if we can nudge Cloudflare regarding this, as it affects connections to many APIs from their workers.

[Omarov3000]

Thank you for your amazing work @JanEbbing!