New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 1533 link

Starred by 3 users

Issue metadata

Status: Verified
Last visit > 30 days ago
Closed: Sep 2008
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

  • Only users with Commit permission may comment.

Sign in to add a comment flash video does not play when it's embedded in a 3rd party web page.

Project Member Reported by, Sep 5 2008

Issue description is #1 youtube-like site in China. 

What steps will reproduce the problem?
1. go to
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: GET 
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/ Safari/525.13
Accept: */*
Accept-Language: zh-CN,zh
Accept-Charset: gb18030,*,utf-8
Accept-Encoding: gzip,deflate,bzip2
Connection: Keep-Alive

Here are IE's headers: GET 
C5114F6C4B05.flv?start=170 HTTP/1.1
Accept: */*
Accept-Language: zh-CN
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

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, Sep 5 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 

Other related links are :


Comment 2 by, Sep 5 2008

Logged this upstream.
There is a related issue on file

Comment 5 by, Sep 24 2008

Status: Fixed
Fixed in chrome revision 2539

Date: Tue Sep 23 17:56:42 2008
New Revision: 2539

This fixes the following bugs:-

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 

Review URL:

Labels: v-154.0
Status: Verified
Project Member

Comment 7 by, Oct 12 2012

Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.

Sign in to add a comment