[whatwg] Redirect handling for <audio> & <video>

[Aaron Colwell]

Thanks for your response.. comments inline

On Fri, Mar 4, 2011 at 1:30 AM, Philip Jägenstedt <philipj at opera.com> wrote:

> On Thu, 03 Mar 2011 22:15:58 +0100, Aaron Colwell <acolwell at google.com>
> wrote:
>
>  Hi,
>>
>> I was looking at the resource fetch
>> algorithm<
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#concept-media-load-resource
>> >section
>> and fetching
>> resources <
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#fetch
>> >
>> sections of the HTML5 spec to determine what the proper behavior is for
>> handling
>> redirects. Both YouTube and Vimeo do 302 redirects to different hostnames
>> from
>> the URLs specified in the src attribute. It looks like the spec says that
>> playback should fail in these cases because they are from different
>> origins (Section 2.7 Fetching resources bullet 7). This leads me to a few
>> questions.
>>
>> 1. Is my interpretation of the spec correct? Sample YouTube & Vimeo URLs
>> are
>>   shown below.
>>   YouTube : src      : http://v22.lscache6.c.youtube.com/videoplayback?
>> ...
>>             redirect : http://tc.v22.cache6.c.youtube.com/videoplayback?
>> ...
>>
>>   Vimeo   : src      : http://player.vimeo.com/play_redirect? ...
>>             redirect : http://av.vimeo.com/05 ...
>>
>
> Yes, from what I can tell you're correct, but I think it's not intentional.
> The behavior was changed by <http://html5.org/r/5111> in 2010-06-25, and
> this is the first time I've noticed it. Opera (and I assume most if not all
> other browsers) already supports HTTP redirects for <video> and I don't
> think it makes much sense to disallow it. For security purposes, the origin
> of the resource is considered to be the final destination, not any of the
> origins in the redirect chain.
>
>
> I agree that redirects should be allowed, but it seems like the force
same-origin flag was introduced to limit the types of redirects. The YouTube
& Vimeo cases mentioned above seem reasonable, but redirects from vimeo.comto
malicious-site.com might not be ok. It looks like the changes reference CORS
as a future solution. Do you have any CORS references that might be helpful?

You also mentioned that the final destination is what should be used for
security. It seems like this could cause problems for canvas.drawImage() (
http://www.whatwg.org/specs/web-apps/current-work/#security-with-canvas-elements)
when trying copy video data to the canvas. If I understand you correctly a
page on YouTube would have to come from the final destination origin to
allow canvas.drawImage() to work. Is that correct?


>  2. What about http: -> https: redirects? Some content is required to be
>> delivered
>>   only via https and this sort of redirect enforces that but isn't really
>> a
>> different origin.
>>
>
> Quoting <
> http://tools.ietf.org/html/draft-abarth-principles-of-origin-00#section-3
> >:
>
> "two URLs are part of the same origin (i.e., represent the same principal)
> if they have the same scheme, host, and port"
>
> Since both the scheme (http vs https) and port (80 vs 443) would be
> different, it's considered a different origin.


I think I made some poor word choices here. I agree that they are different
origins because the scheme and port are different. I was just trying to get
at the fact they still referred to the same content just over a secure
connection. It seems like there are use cases where a set of <scheme, host,
port> tuples should be considered a single origin from a security point of
view. It just isn't clear to me how we are supposed to express that.


>
>  3. If my interpretation of the spec is correct, are there proposals to
>> change this
>>   or other specs that allow content providers to signal that these
>> different hostnames
>>   actually represent the same "origin".
>>
>
> I think the force same-origin flag introduced by <http://html5.org/r/5111>
> should be removed from the resource fetch algorithm, but the http vs https
> origin issue is not something that can really be changed.
>

So what is the process for proposing this type of change? Is this the right
forum?
Why is allowing redirects with the same scheme but different hosts ok, but
redirecting different schemes with the same host not ok? I'm new to this so
I'm just trying to understand.


Aaron