Re: [whatwg/fetch] Hide range values from no-cors cross-origin range requests (Issue #1936)

edenchuang left a comment (whatwg/fetch#1936)

> I'd like to discuss three options at WHATNOT:
> 
>     * Revealing the byte size of a cross-origin valid media resource is fine. We already reveal duration, and something having the same duration and a different byte size will be very rare.
> 
>     * We hide the range header value. Risks: The developer doesn't know a request is a range request, and may act incorrectly based on the false information. It becomes a tricksy part of the platform.
> 

The developer might still know this is a range request, because they can check the response status of fetch(event.request). It would get 216/406, which implies this is a range request.

>     * We lie about the range header value (`0-`). The developer knows it's a range request. However, the incorrect value may still result in them acting incorrectly based on the false info. It's still a tricksy part of the platform.

I think option 3 is just a variant of option 2. In general, they have no difference.  Because I think the main issue is offline handling, as there is no network to fetch the response.

In option 2, since the response from the network should be a NetworkError response, SW has no idea that this is a range request. SW could provide two kinds of responses. Notice that there is no cached response to use, since a partial response could not be saved in the cache.
1. A NetworkError response, by fetching the response from the network.
2. A SW synthesized response.
The SW synthesized response would not pass the range request response-matching check, so it eventually still goes to a NetworkError.

In option 3, the same: even though SW knows this is a range request, I don't think SW can handle it properly, since there is no cached response and the wrong range is received. So the same SW probably provides the following two kinds of response.
1. A NetworkError response, by fetching the response from the network.
2. A SW synthesized range response.

The same synthesized response would not pass the range request response-matching check due to incorrect range information. So it still eventually goes to a NetworkError. 

So IMO, if the results are the same for option 2 and option 3, IMO, I don't think exposing a wrong range really helps anything.
If possible, I would like to hint to developers that they probably need to set CORS mode for media loading when they meet the case.

> 
> 
> <video src="//other-origin/whatever.mp4"></video>
> 
> In the service worker:
> 
> onfetch = (event) => {
>   console.log(event.request.headers.get('range'));
> 
>   event.respondWith(fetch(event.request));
> };



-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/1936#issuecomment-4799748833
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/issues/1936/4799748833@github.com>