Re: [whatwg/fetch] Cross-Origin Read Blocking (CORB) (#681)

> When service workers cache actual cross-origin responses (e.g. in ‘no-cors’ request mode), the responses are ‘opaque’ and therefore CORB can block such responses without changing the service worker's behavior (‘opaque’ responses have a non-accessible body even without CORB).

Opaque responses have a hidden body, yes, but the Cache entry still contains the filtered body.  It must still be there for the service worker to use the Cache to service no-cors requests like <img>, etc.

It seems CORB would require that Cache.match() not send the opaque body data to the renderer process until after the CORB checking is performed.  The CORB checking would depend on what the service worker does with the opaque response. (If I understand correctly the CORB check requires knowing the destination of the response within the browser.)

FWIW, this does part does seem doable to me from an implementation perspective. Gecko's cache waits to open the body file descriptor until body consumption begins.  So as long as we can perform the CORB check in the renderer process as part of the respondWith() call, then it seems possible to achieve this.

-- 
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/681#issuecomment-375940740