Distinguishing between errors

[bitinn]

Since we are rejecting with a TypeError when the Response is type error (aka network error per spec), what's your suggestion on how to distinguish between unparseable url, broken location header, network timeout, redirect limit reached.

Is checking error message the suggested way?

This might be less of a problem on client side, but when implemented on server side, once I allowed custom timeout and maximum redirect count, that error is no longer solely caused by remote resource, it can also be related to request config. This is a concern for debugging and logging purposes.

for server-side implementation, see node-fetch, also related to #20.

[domenic]

This is kind of a giant unsolved problem in web APIs. I last contributed on es-discuss about this. /cc @sicking

[sicking]

Yeah, I was also not able to make any progress here. Didn't seem like there was any form of agreement on what errors on the web should look like.

[annevk]

The main reason we do not have granularity for "network error" (which results in TypeError here) is because we do not want to give attackers more information about the network than strictly needed.

On the server this is probably less of a concern. Perhaps just adding an expando on the TypeError object as a hack? A server-side implementation obviously doesn't have to follow the constraints we have.

[annevk]

@bitinn any thoughts? I'm inclined to close this.

[bitinn]

@annevk sure! just one question: did current browser-side Fetch implementation leak information about the cause of TypeError by sending different .message string? Or do they send the exact same err.message?

I am just wondering as our current implementation is to send different message so debugging is easier.

[annevk]

@bitinn I'm not sure if they do, I hope not for what the specification calls network errors. Though I suppose they might safely distinguish between an invalid URL and network error in the message and maybe the specification should too at some point if JavaScript gains a decent way to do that.

[tyoshino]

For #25 (comment), Chromium doesn't give the detailed reason of fetch() failure to the script. /cc @horo-t @yutakahirano

[determin1st]

what is so giant to throw Error with too many redirects message? (it somehow throws but i unable to stop/debug it)

the restriction doesnt give app to decide anything except generic error: