Bugzilla

(In reply to Anne (:annevk) from comment #3)
> The only other thing I can think of is that synthetic responses would not be allowed for "no-cors" media elements that make requests across the origin boundary. You could still use cached responses however assuming the URLs match up. It's not clear how web compatible that would be.

Media elements have their own fallback mechanisms for network failures (Source child elements and/or MediaSource), so I don't know of a good additional use case for synthetic responses for cross-origin "no-cors" requests.

The key question is web-compatibility, and I don't know the answer to that.

As for the benefits of disallowing such responses, there are two areas of risk here.

The first is that synthesized responses can be used to make media elements generate specific no-cors Range requests, which might not otherwise be available but could then be passed on to `fetch()` when we add support for passing on Range headers (bug 1465074).
Disallowing such responses would address this.

The second is that sending media element requests to ServiceWorker is exposing a lower bound on the length of the opaque cross-origin resource.
Completely addressing this would require that no-cors cross-origin requests are not sent to ServiceWorker at all.

(In reply to Anne (:annevk) from comment #3)
> The only other thing I can think of is that synthetic responses would not be allowed for "no-cors" media elements that make requests across the origin boundary. You could still use cached responses however assuming the URLs match up. It's not clear how web compatible that would be.

Media elements have their own fallback mechanisms for network failures (Source child elements and/or MediaSource), so I don't know of a good additional use case for synthetic responses for cross-origin "no-cors" requests.

The key question is web-compatibility, and I don't know the answer to that.

As for the benefits of disallowing such responses, the area of risk addressed would be in preventing use of synthesized responses to make media elements generate specific no-cors Range requests, which might not otherwise be available but could then be passed on to `fetch()` when we add support for passing on Range headers (bug 1465074).

It would not address either of these risks:
* Unsanctioned cross-path redirects mixing same-cross-origin opaque resources.  (Multiple solutions are available.)
* Sending media element requests to ServiceWorker is exposing a lower bound on the length of the opaque cross-origin resource.  Addressing this would require that no-cors cross-origin requests (or at least parts of them) are not readable by ServiceWorker.

(In reply to Anne (:annevk) from comment #3)
> The only other thing I can think of is that synthetic responses would not be allowed for "no-cors" media elements that make requests across the origin boundary. You could still use cached responses however assuming the URLs match up. It's not clear how web compatible that would be.

Media elements have their own fallback mechanisms for network failures (Source child elements and/or MediaSource), so I don't know of a good additional use case for synthetic responses for cross-origin "no-cors" requests.

The key question is web-compatibility, and I don't know the answer to that.

As for the benefits of disallowing such responses, the area of risk addressed would be in preventing use of synthesized responses to make media elements generate specific no-cors Range requests, which might not otherwise be available but could then be passed on to `fetch()` when we add support for passing on Range headers (bug 1465074).

It would not address either of these risks:
* Unsanctioned cross-path redirects mixing same-cross-origin opaque resources.
* Sending media element requests to ServiceWorker is exposing a lower bound on the length of the opaque cross-origin resource.  Addressing this would require that no-cors cross-origin requests (or at least parts of them) are not readable by ServiceWorker.