-
Notifications
You must be signed in to change notification settings - Fork 330
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CORB: empty response VS erroring out #727
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? |
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 |
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 (#560). Are you ok with that too? |
Yup. |
Sold. |
In a few cases people wondered why CORB blocking does't result in a network error:
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...).
The text was updated successfully, but these errors were encountered: