Change fetch description to match real world experience

[fozcode]

Description

Attempt to better describe the behaviour of fetch.

Motivation

The previous wording was misleading because fetch does in fact reject for some HTTP status codes.

Additional details

Documents the behaviour seen today in Chrome 114.0.5735.198

Related issues and pull requests

[Josh-Cena]

Does it reject on 400? See #17115. We would probably need to be comprehensive here about what statuses lead to rejection.

[fozcode]

The situation appears to be complicated.

For my test case, in Chrome:

Status code	Rejects
400	no
401	no
402	no
403	no
404	no
405	no
406	no
407	yes
408	no
413	no
421	no
431	no

Meanwhile Firefox does not reject for 407.

So the rejection for 407 in Chrome is arguably a Chrome bug, or perhaps it can be said that the result is implementation dependent.

[fozcode]

I probably should have consulted Stack Overflow earlier but it seems this is not a new situation:
https://stackoverflow.com/questions/60753827/fetch-api-handle-error-407-is-not-same-between-chrome-and-firefox

[github-actions]

Preview URLs

• /en-US/docs/Web/API/fetch

(comment last updated: 2024-03-18 17:08:35)

[sideshowbarker]

We need to document what the spec says the required behavior is, and add notes indicating what browsers don’t conform to the behavior the spec requires.

https://fetch.spec.whatwg.org/#ref-for-concept-response-status①⑧ is the part of the spec that defines how browsers are required to handle 407 errors.

[annevk]

This would probably benefit from some web-platform-tests so we can analyze the differences. In any event the specification does not require rejection. It requires handling 407 by the user agent, which is not very different from it requiring handling 301.

[github-actions]

This pull request has merge conflicts that must be resolved before it can be merged.

[bsmth]

Thanks for raising this one @fozcode.

I looked through the Chromium bug tracker and there's a few related to this behavior, but this seems to explain what's going on: https://issues.chromium.org/issues/41401857

When we get a 407, we immediately try to handle it in http_network_transaction. When that fails, we return ERR_UNEXPECTED_PROXY_AUTH. This is probably the right thing to do in general, but per the XHR spec, we're supposed to read the body and return everything as a successful XHR response.

So this is Chrome-only and it looks like it should be a note in BCD (in 407 response?) with a link to https://issues.chromium.org/issues/41401857

(related: https://groups.google.com/a/chromium.org/g/chromium-bugs/c/JnTQ5DWyE4A/m/RT18gr_sdLMJ)

I can also suggest we close this PR to leave the prose as-is, what do you think?

[fozcode]

Thanks for reviewing this @bsmth. I didn't realise the situation was specific to 407 in Chrome when I raised the PR. Given that it is, I have no objections to closing this.

Though it is now off-topic, the original text says that a rejection due to a network error is "usually when there's a permissions issue". That seems oddly specific in my opinion, when it might be that the destination is unreachable for a dozen other reasons.

[bsmth]

Thanks for reviewing this @bsmth. I didn't realise the situation was specific to 407 in Chrome when I raised the PR. Given that it is, I have no objections to closing this.

Though it is now off-topic, the original text says that a rejection due to a network error is "usually when there's a permissions issue". That seems oddly specific in my opinion, when it might be that the destination is unreachable for a dozen other reasons.

Yes, I agree it's not super clear. I've left a suggestion above, what do you think? We may try to clean it up here and rename the PR title to reflect that.

[fozcode]

I've accepted the suggestion. Versus the original text it is clearer that in one situation there is no response, while in the other there is a response but it's an error.

[bsmth]

Super, thank you very much. I think we can leave the PR title as-is and merge! We also need a BCD issue to track the 407 behavior on Chrome as a follow-up (I can do this).