- From: Lukasz Anforowicz <notifications@github.com>
- Date: Mon, 21 May 2018 11:56:25 -0700
- To: whatwg/fetch <fetch@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/fetch/issues/727@github.com>
In a few cases people wondered why [CORB](https://github.com/whatwg/fetch/issues/681) blocking does't result in a network error: - @annevk [in a CORB PR](https://github.com/whatwg/fetch/pull/686#issuecomment-376790056): "Are you planning on changing the implementation to use a network error for the cases enumerated in the PR?" - @mikewest [in a From-Origin comment](https://github.com/whatwg/fetch/issues/687#issuecomment-390555524): "CORB does not fail the load, but instead delivers a filtered response. I don't have a strong feeling about which behavior we ought to end up with, but I do think that diverging would be confusing. I'd prefer for us to align the response that's returned from both From-Origin and CORB if we're going to fold their processing model together. My intuition is that that's simpler to do by treating both as network errors" - @youennf [in a From-Origin comment](https://github.com/whatwg/fetch/issues/687#issuecomment-390722953): "A network error seems consistent with other fetch error handling." Based on what @csreis [wrote](https://github.com/whatwg/fetch/pull/686#issuecomment-381256391) it seems that there are no specific backcompatibility concerns here (and to change Chromium implementation we just need to do the grunt work of making sure that CORB console messages and prefetching/caching behavior are preserved in presence of CORB-induced network errors). Let me reactivate https://crbug.com/827633 (although I am not sure what would be the timeline for working on this bug...). -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/whatwg/fetch/issues/727
Received on Monday, 21 May 2018 18:56:49 UTC