Not compatibility with Cloudflare Workers

[looch]

Trace: Error: The 'credentials' field on 'RequestInitializerDict' is not implemented.

And

Your worker created multiple branches of a single stream (for instance, by calling response.clone() or request.clone()) but did not read the body of both branches. This is wasteful, as it forces the system to buffer the entire stream of data in memory, rather than streaming it through. This may cause your worker to be unexpectedly terminated for going over the memory limit. If you only meant to copy the request or response headers and metadata (e.g. in order to be able to modify them), use the appropriate constructors instead (for instance, new Response(response.body, response), new Request(request), etc).

[XantreDev]

Crazy that this is still an issue. Which wrapper around fetch can anyone recommend?

[sphr2k]

@haverstack/axios-fetch-adapter works for me.

[XantreDev]

axios weight is huge. It's not the a good thing for my use case

[suhaotian]

@XantreGodlike Do you want give a try of xior ? gzip less than 3kb

[XantreDev]

@suhaotian it's fixed in ky by now. But I will continue using fetch for my use case

[suhaotian]

@XantreGodlike Nice! xior use fetch too, similar axios API, if you want more plugins, xior is your choice.. Thanks reply :)

[KazimirPodolski]

@suhaotian just tried to replace ky with xior and turns out it does much better job with error reporting by default. XiorError has everything, ky's HTTPError miss important stuff (full URL, response body, etc) including completely non-important (hooks? ky's methods? status codes? wtf?). Plus xior has no ESM-only autism. Great job!

[XantreDev]

Should we close the issue?

[sholladay]

@KazimirPodolski the documentation for HTTPError could use some improvement but it should have everything you need...

error.request.url;      // full URL
error.response.json();  // response body

We could add the request method and URL to the error.message, too, if that would be helpful.

[sholladay]

Closing as this issue was fixed in PR #559

[KazimirPodolski]

@sholladay defaults are impractical, e.g. response is not even there by default, but it's the place where usually meaningfull error might be.

Error reporting of a request to an HTTP endpoint is already inconsistent and confusing in the wild, and we already have places to waste time setting it up (e.g. web frameworks). I just don't want to do it for fetch wrapper too...

[sholladay]

defaults are impractical, e.g. response is not even there by default, but it's the place where usually meaningfull error might be.

I'm not sure what you mean. The response is always there if Ky received one, it's at error.response. Do you mean to say you want the response body to be parsed automatically? As in, you wish that we provided error.body instead of error.response.json()? Or that you wish we would parse the body and find some kind of error message in it and then copy that message to error.message? I don't think that's a good idea because it would consume the response stream and who knows what the format of the body is beyond just the basic Content-Type, but we could consider it.

Error reporting of a request to an HTTP endpoint is already inconsistent and confusing in the wild, and we already have places to waste time setting it up (e.g. web frameworks). I just don't want to do it for fetch wrapper too...

I agree with you, error handling on the web platform is in bad shape. It only gets worse when HTTP is involved and worse still when a backend app wants to report errors of its own to the frontend.

There is a decent partial solution to this with RFC 9457. That would at least give Ky something standardized to parse in the response body. We would still have to consider whether it's worth automatically consuming the response stream in order to expose these details and whether we want to support both JSON and XML, but I would love to see some exploration of how we could make use of RFC 9457.