Contact [email protected] Specificationhttps://github.com/whatwg/fetch/pull/1442
Summary Opaque Response Blocking (ORB) is a replacement for Cross-Origin Read Blocking (CORB - https://chromestatus.com/feature/5629709824032768). CORB and ORB are both heuristics that attempt to prevent cross-origin disclosure of “no-cors” subresources. This entry tracks "v0.2" of ORB - Chrome's second step towards a full ORB implementation. ORB specifies error handling for blocked resources differently from CORB: ORB raises network errors, while CORB injects an empty response. ORB "v0.1" still used CORB-style response injection. This change brings our implementation more in line with the ORB proposal, by changing the error handling of all fetches (except when initiated by a script) to be compliant with ORB. We've made a carve-out for script-initiated fetches (where we retain CORB behaviour for now) to limit compatibility risk. Blink componentInternals>Sandbox>SiteIsolation <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3ESandbox%3ESiteIsolation> TAG reviewNone (A TAG review of a particular aspect happened in: https://github.com/w3ctag/design-reviews/issues/618) TAG review statusNot applicable Risks Interoperability and Compatibility This release does not modify blocking behaviour, but only how a blocked resource is represented. Ideally, this change shouldn't break any existing code since any resource that loads (or gets blocked) before will continue to do so after. However, it is possible to distinguish between the different types of error handling, and it may well happen that an application inadvertently relies on blocked resources "succeeding". In our examinations so far, this chiefly concerns fetches using the `fetch()` API, where blocking with a network error results in a failed promise (instead of a success with an empty response). For this reason, we have carved out script-initiated fetches from "v0.2" and intend to handle them at a later date. *Gecko*: No signal (https://bugzilla.mozilla.org/show_bug.cgi?id=1532642) In implementation. *WebKit*: No signal (https://github.com/WebKit/standards-positions/issues/64 ) *Web developers*: No signals *Other signals*: https://github.com/w3ctag/design-reviews/issues/618 WebView application risks Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications? None Debuggability Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?Yes Is this feature fully tested by web-platform-tests <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> ?Yes (https://wpt.fyi/results/fetch/orb) Flag name on chrome://flags Finch feature nameOpaqueResponseBlockingV02 Requires code in //chrome?False Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1463725 Estimated milestones Shipping on desktop 117 DevTrial on desktop 115 Shipping on Android 117 DevTrial on Android 115 Shipping on WebView 117 Anticipated spec changesNone Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5166834424217600 Links to previous Intent discussions https://groups.google.com/a/chromium.org/g/blink-dev/c/ScjhKz3Z6U4 This intent message was generated by Chrome Platform Status <https://chromestatus.com/>. -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6KPPNdN%3DO0j0MhcfudkBtMoYnELhVRJ5nLftB8c1T1UdwbQ%40mail.gmail.com.
