My favorites | Sign in
Logo
             
New issue | Search
for
| Advanced search | Search tips
Issue 1533: youku.com flash video does not play when it's embedded in a 3rd party web page.
3 people starred this issue and may be notified of changes. Back to list
Status:  Verified
Owner:  ananta@chromium.org
Closed:  Sep 2008
Cc:  jshin@chromium.org
Type-Bug
Pri-2
OS-All
Area-Unknown
v-154.0


Sign in to add a comment
 
Reported by jshin@chromium.org, Sep 05, 2008
Youku.com is #1 youtube-like site in China. 

------------------------
What steps will reproduce the problem?
1. go to http://www.oneava.cn/read.php?tid=49
2. wait a a few second 
3. press a large play button in the middle of 'flash' frame 

What is the expected output? What do you see instead?

Flash movie should be played. Instead, we get an error message in Chinese.

Please use labels and text to provide additional information.
 
Here's the analysis (slightly paraphrased from the orignal emial report):

----------------------
Here are the headers caught with chrome:

060.247.104.099.07961-059.175.133.025.00080: GET 
/19678964764/020064010048425D28CABD00380F414E90E8FF-9EB6-4DCF-0858-
C5378F42C4EC.flv HTTP/1.1
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) 
AppleWebKit/525.13 (KHTML, like Gecko) Chrome/0.2.149.27 Safari/525.13
Referer: http://www.oneava.cn/read.php?tid=49
Accept: */*
Accept-Language: zh-CN,zh
Accept-Charset: gb18030,*,utf-8
Accept-Encoding: gzip,deflate,bzip2
Host: 59.175.133.25
Connection: Keep-Alive

Here are IE's headers:

060.163.233.090.03560-059.175.133.025.00080: GET 
/196f7764764/020064070047241199C96F0048CFA690E8D0F3-B2A8-7E99-061C-
C5114F6C4B05.flv?start=170 HTTP/1.1
Accept: */*
Accept-Language: zh-CN
Referer: http://static.youku.com/v1.0.0320/v/swf/qplayer.swf
x-flash-version: 9,0,124,0
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
Connection: Keep-Alive
Host: 59.175.133.25

Basically they need to check the referer to make sure the request comes 
from the flash they created, instead of a download link. IE gives referer 
as the url of flash swf, while chrome gives the url of the page, which 
fails their check. It seems they do have the need to confirm referer. Is it 
that we are doing it wrong?

Comment 1 by jshin@chromium.org, Sep 05, 2008
The value of Referer: field is different in different browsers. There's a recent mail 
from an Opera engineer about the issue in NPAPI plugin-future mailing list. (I can't 
give a url because the archive is protected).  

The gist of that email is :

IE8 : sends the URL of the requesting plug-in 
Firefox3: does not send a refere (except in a very special case : [3])
Safari 3.1 : does not send a referer
Chrome : sends the embedding page URL
Opera : sends the embedding page URL

It seems that webkit (as used in Safari 3.1 newer than as used in Chrome) does not 
send a referer and not sending referer works for sites like youku.com. 


Other related links are :

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=410904
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=383708
[3] http://www.actionscript.org/forums/showthread.php3?t=164503



Comment 2 by jshin@chromium.org, Sep 05, 2008
(No comment was entered for this change.)
Owner: all-bugs...@chromium.org
Comment 3 by ananta@chromium.org, Sep 08, 2008
Logged this upstream. https://bugs.webkit.org/show_bug.cgi?id=20739
There is a related issue on file https://bugs.webkit.org/show_bug.cgi?id=18165


Comment 4 by ananta@chromium.org, Sep 08, 2008
(No comment was entered for this change.)
Owner: ana...@chromium.org
Comment 5 by ananta@chromium.org, Sep 23, 2008
Fixed in chrome revision 2539

Author: iyengar@google.com
Date: Tue Sep 23 17:56:42 2008
New Revision: 2539

Log:
This fixes the following bugs:-
1. http://code.google.com/p/chromium/issues/detail?id=1473
2. http://code.google.com/p/chromium/issues/detail?id=1533

Our plugin implementation currently sends the containing frame URL
as the default referer in HTTP requests initiated by plugins. Based
on a discussion on the Plugin futures mailing list, an agreement
has been reached to mimic IE behavior and send in the plugin source
URL as the default referer in plugin requests. If the plugin is instantiated
with an empty SRC, then use the containing frame URL as the referer.

Bug=1473,1533
R=jam

Review URL: http://codereview.chromium.org/3180


Status: Fixed
Comment 6 by venkataramana@chromium.org, Oct 02, 2008
(No comment was entered for this change.)
Status: Verified
Labels: v-154.0
Sign in to add a comment