Fetch: CORB: empty response VS erroring out

Created on 21 May 2018  ·  5Comments  ·  Source: whatwg/fetch

In a few cases people wondered why CORB blocking does't result in a network error:

  • @annevk in a CORB PR: "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: "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: "A network error seems consistent with other fetch error handling."

Based on what @csreis wrote 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...).

corb

Most helpful comment

Are you ok with that too?

Yup.

All 5 comments

Here's the problem:

fetch('https://example.com/whatever', { mode: 'no-cors' }).catch(() => {
  // This smells like a CORB-blocked resource.
});

The question is, is this an acceptable data leak?

The question is, this is an acceptable data leak?

It seems like the data you can infer from the error is fairly narrow: "This resource had an interesting MIME type." Are there cases where that's revealing more than we'd like?

Also: if we expand the conditions under which we return a network error (e.g. by making that From-Origin's behavior as well), then we further reduce the granularity of the assumptions an attacker can make.

It's mostly interesting if that content changes when the user is logged in or not. But I agree that if there are a lot of cases that return network-error, then the assumption isn't as useful.

Whatever we do here, I'd like to do the same for step 8 of https://whatpr.org/fetch/560.html#main-fetch (https://github.com/whatwg/fetch/pull/560). Are you ok with that too?

Are you ok with that too?

Yup.

Sold.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

annevk picture annevk  ·  9Comments

jovdb picture jovdb  ·  8Comments

jakearchibald picture jakearchibald  ·  5Comments

tomayac picture tomayac  ·  13Comments

tusharmath picture tusharmath  ·  10Comments