Bugzilla

(In reply to Anne (:annevk) from comment #3)
> The model I have in mind for media elements is that they make an initial request and then multiple subsequent requests. The final redirected URL of the initial request is what is used by subsequent requests. (This matches Chrome as far as I can tell.)

This is somewhat consistent with Gecko behavior, but the final redirected path of [each subsequent request is used](https://searchfox.org/mozilla-central/rev/73a6abf1aaedbf7613fa90a7f459a8c0dfe5f0ce/dom/media/ChannelMediaResource.cpp#398) for the next request.

> If subsequent requests redirect, terminate. (This used to match Chrome, but they changed things. Reportedly they're flexible on this though.)
> 
> That's how you'd do requests. Then for responses you'd keep track of their origin and the moment you get a response from a different origin you'd terminate.

In Gecko, subsequent responses will terminate only [when origins differ]( https://searchfox.org/mozilla-central/rev/66b43502bdbe4b62cbc8b0c8ff10efc5707352e4/dom/media/ChannelMediaResource.cpp#807).

If the cross-origin server (rather than the service worker) chooses to redirect to a different path but same (cross-)origin, then I'm not aware of a problem with that.

I'm uncomfortable with allowing service workers to coerce a mixture of same-cross-origin but different-path opaque responses by emulating a path redirect through returning an opaque response from a fetch with different path.
A cached response from a ServiceWorker with a different path would currently be treated by media element like a redirect.
AFAIK that is not possible to abuse until ServiceWorker can pass on the Range headers (bug 1465074), but I haven't investigated whether a 200 OK response to a different-path request would overwrite the media resource from a 206 Partial Content initial response or whether it might lead to problematic mixing of different opaque resources.

(In reply to Anne (:annevk) from comment #3)
> The model I have in mind for media elements is that they make an initial request and then multiple subsequent requests. The final redirected URL of the initial request is what is used by subsequent requests. (This matches Chrome as far as I can tell.)

This is somewhat consistent with Gecko behavior, but the final redirected path of [each subsequent request is used](https://searchfox.org/mozilla-central/rev/73a6abf1aaedbf7613fa90a7f459a8c0dfe5f0ce/dom/media/ChannelMediaResource.cpp#398) for its next request.

> If subsequent requests redirect, terminate. (This used to match Chrome, but they changed things. Reportedly they're flexible on this though.)
> 
> That's how you'd do requests. Then for responses you'd keep track of their origin and the moment you get a response from a different origin you'd terminate.

In Gecko, subsequent responses will terminate only [when origins differ]( https://searchfox.org/mozilla-central/rev/66b43502bdbe4b62cbc8b0c8ff10efc5707352e4/dom/media/ChannelMediaResource.cpp#807).

If the cross-origin server (rather than the service worker) chooses to redirect to a different path but same (cross-)origin, then I'm not aware of a problem with that.

I'm uncomfortable with allowing service workers to coerce a mixture of same-cross-origin but different-path opaque responses by emulating a path redirect through returning an opaque response from a fetch with different path.
A cached response from a ServiceWorker with a different path would currently be treated by media element like a redirect.
AFAIK that is not possible to abuse until ServiceWorker can pass on the Range headers (bug 1465074), but I haven't investigated whether a 200 OK response to a different-path request would overwrite the media resource from a 206 Partial Content initial response or whether it might lead to problematic mixing of different opaque resources.