Define opaque-response blocking

[annevk]

This is good enough for early review.

TODO:

• [ ] Define "validate a partial response" (and Content-Range header parser)
• [x] "ParseText" vs "create a classic script" + mock data
• [ ] A PR against HTML is needed to ensure it passes the appropriate metadata for media element and classic script requests.
• [x] Double check this operates on the internal response (and if not pass it)
• [x] Also use response in encoding extraction, depends on https://github.com/whatwg/fetch/pull/1447
• [ ] https://github.com/annevk/orb/labels/mvp

---

• [x] At least two implementers are interested (and none opposed):
  • Chrome
  • Firefox
• [ ] Tests are written and can be reviewed and commented upon at:
  • …
• [ ] Implementation bugs are filed:
  • Chrome: …
  • Firefox: …
  • Safari: …
  • Deno (not for CORS changes): …

(See WHATWG Working Mode: Changes for more details.)

---

Preview | Diff

[annevk]

@domenic thoughts on "ParseText" vs "create a classic script" + mock data?

[domenic]

So I think using ParseText here is pretty clean, especially since ParseScript seems to really prefer you giving it a Realm (even though it's used just for pass through).

However there may be a slight issue here, which is that ParseText does early-error detection. I wonder if people really plan to do early-error detection (which IIUC involves pretty detailed JavaScript engine semantics) inside the network code where ORB is implemented.

[sefeng211]

Does the spec cover the case where service worker synthesizing a response, so the synthesized response shouldn't be blocked by ORB if service worker's request passes?

[annevk]

Yes, if you look at https://whatpr.org/fetch/1442.html#http-fetch it currently handles service workers in step 5. Then in step 6, if there's still no response, it'll do a network fetch in substep 3. Then in substep 4 it'll do the opaque-response-safelist check. This is also clarified in a note at the end of step 6.