Last Comment Bug 410904 - http_referer request not being sent with embedded flash
: http_referer request not being sent with embedded flash
Status: VERIFIED FIXED
[qa!]
: regression
Product: Core
Classification: Components
Component: Plug-ins (show other bugs)
: unspecified
: All All
: -- major with 98 votes (vote)
: mozilla13
Assigned To: Cellier fabien [:fcellier]
:
Mentors:
http://dev.deconcept.com/referer_tester/
: 383708 409119 443562 452864 480195 529214 532364 534976 542205 577551 660854 724877 737903 756831 (view as bug list)
Depends on: 722004 722855 724405 724465 726133 727820 729009
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-05 03:22 PST by Xavier K
Modified: 2012-05-19 16:25 PDT (History)
55 users (show)
benjamin: blocking1.9.2-
benjamin: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
wontfix
+
verified


Attachments
Add referrer with http request (1.68 KB, patch)
2011-12-19 12:52 PST, Cellier fabien [:fcellier]
bzbarsky: review-
jaas: review-
jaas: feedback+
bzbarsky: feedback+
Details | Diff | Splinter Review
Add referrer with http request (1.68 KB, patch)
2012-01-11 10:16 PST, Cellier fabien [:fcellier]
jaas: review+
Details | Diff | Splinter Review
this video won't play with wrong referer. (428 bytes, text/html)
2012-02-20 08:33 PST, dindog
no flags Details

Description Xavier K 2008-01-05 03:22:56 PST
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11

Let me start of by saying this is not a duplicate of bug 337766.  His request was geared towards http_referer being manually inserted into the flash object.  

I have link protection enabled on my website to protect copyrighted images from being downloaded. I also have an embedded flash based slideshow that displays the images inside the browser. The http_referer seems to be handled by Internet Explorer, so the request for the image is processed. This is not the case with Firefox. The request is being denied due to a non-existing/non-valid http_referer. I have had others test it with Camino and the problem seems to exist there as well. They have reported that it also works in Safari.  I have tested this by allowing non-existing referers (Direct URL requests), and it works.  The slideshow users the LoadMovie() object inside of Flash.

Affected Domain Logs:
__________________________________________________
1.2.3.4 - - [05/Jan/2008:02:30:55 -0600] "GET /1.jpg HTTP/1.1" 403 - "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11"
__________________________________________________

I also have an open forum located here: http://forums.mozillazine.org/viewtopic.php?t=617988.  Additionally, I have contact jmott from Macromedia and requested his involvement, if for nothing else, to confirm my request.



Thank you,

Xavier

Reproducible: Always

Steps to Reproduce:
1.  Go to http://test.dlsgallery.com for a non-working model
2.  Go to http://test2.dlsgallery.com for a working model
3.
Actual Results:  
Http_referer is not being sent to the webserver, causing a deny in request.

Expected Results:  
http_referer being returned to the webserver as an embedded object

Here is a copy of the htaccess file that is on test.dlsgallery.com that is affecting the slideshow

    RewriteEngine on
    RewriteCond %{HTTP_REFERER} !^http://www.test.dlsgallery.com/.*$      [NC]
    RewriteCond %{HTTP_REFERER} !^http://www.test.dlsgallery.com$      [NC]
    RewriteCond %{HTTP_REFERER} !^http://test.dlsgallery.com/.*$      [NC]
    RewriteCond %{HTTP_REFERER} !^http://test.dlsgallery.com$      [NC]
    RewriteRule .*\.(jpg|jpeg|gif|png|bmp)$ - [F,NC]

Here is a copy of the htaccess on test2 that allows the slideshow to work

    RewriteEngine on
    RewriteCond %{HTTP_REFERER} !^$
    RewriteCond %{HTTP_REFERER} !^http://www.test2.dlsgallery.com/.*$      [NC]
    RewriteCond %{HTTP_REFERER} !^http://www.test2.dlsgallery.com$      [NC]
    RewriteCond %{HTTP_REFERER} !^http://test2.dlsgallery.com/.*$      [NC]
    RewriteCond %{HTTP_REFERER} !^http://test2.dlsgallery.com$      [NC]
    RewriteRule .*\.(jpg|jpeg|gif|png|bmp)$ - [F,NC]
Comment 1 Dave Townsend [:mossop] 2008-01-05 03:25:03 PST

*** This bug has been marked as a duplicate of bug 337766 ***
Comment 2 Xavier K 2008-01-05 03:28:01 PST
(In reply to comment #1)
> 
> *** This bug has been marked as a duplicate of bug 337766 ***
> 

As I stated, this is not a duplicate of bug 337766.
Comment 3 Dave Townsend [:mossop] 2008-01-05 03:30:58 PST
Yes it is, See comment 5 where it states that they do not set the referer header for flash requests for security reasons.


*** This bug has been marked as a duplicate of bug 337766 ***
Comment 4 Xavier K 2008-01-05 03:36:30 PST
They do not, that doesn't mean Firefox shouldn't.  This is an embedded object that is making the request.  Firefox should process that internally recognizing it is not a unique request, and attach the necessary code.

This is a major bug that interferes with Firefox's ability to support what other browsers do.

Macromedia, may not support the header, but that doesn't mean Firefox shouldn't.  It is required for compatibility.  Otherwise people will be forced to use other browsers such as IE, where it works perfectly.  I am to assume then that Microsoft took the time to modify their code to support the http_referer around an embedded object.



Xavier
Comment 5 Steve England [:stevee] 2008-01-05 03:57:46 PST

*** This bug has been marked as a duplicate of bug 337766 ***
Comment 6 Reed Loden [:reed] (use needinfo?) 2008-01-05 04:04:13 PST

*** This bug has been marked as a duplicate of bug 337766 ***
Comment 7 Reed Loden [:reed] (use needinfo?) 2008-01-05 04:11:45 PST
Can you explain one more time why you don't think this is a dupe of bug 337766?
Comment 8 Xavier K 2008-01-05 04:27:44 PST
Jeff's request was that they were trying to pass internal data from within flash to Firefox.  My request is the interaction between the server and the browser.  To detect and append the necessary information to complete a valid request from the server side.  Adobe Flash has no way to read the referer information, thus it can't return it.

They don't support it, because what would stop me from opening flash, creating a script that embedded a false http_referer so I can spoof a request from a website.    As you can see from this snipet of log, it is firefox that is making the end request to the webserver.  It isn't Flash making the request.  Everything until this request has the http_referer embedded.

Affected Domain Logs:
__________________________________________________
1.2.3.4 - - [05/Jan/2008:02:30:55 -0600] "GET /1.jpg HTTP/1.1" 403 - "-"
"Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.11) Gecko/20071127
Firefox/2.0.0.11"
__________________________________________________

Here is a copy of the log from a request in an IE browser.
__________________________________________________

1.2.3.4 - - [05/Jan/2008:06:25:35 -0600] "GET /1.jpg HTTP/1.1" 200 62205 "http://test.dlsgallery.com/test.swf" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; Windows-Media-Player/10.00.00.3990; InfoPath.2; .NET CLR 3.0.04506.648)"
1.2.1.4 - - [05/Jan/2008:06:25:42 -0600] "GET /2.jpg HTTP/1.1" 200 69567 "http://test.dlsgallery.com/test.swf" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; Windows-Media-Player/10.00.00.3990; InfoPath.2; .NET CLR 3.0.04506.648)"
__________________________________________________


Xavier
Comment 9 Matthias Versen [:Matti] 2008-01-05 04:55:05 PST
Does Opera send a referer because they are also using the npapi plugin ?
Are other plugins send a referer like for example quicktime playing a mp3 ?
Comment 10 Xavier K 2008-01-05 05:02:38 PST
I just downloaded and installed Opera.  It worked out of the box.  I didn't have to do anything.  I've been watching the logs, please see below.


1.2.3.4 - - [05/Jan/2008:06:58:02 -0600] "GET /1.jpg HTTP/1.1" 403 - "-" "Mozilla/5.0 (Windows; U; Windows NT 6.0; rv:1.9b3pre) Gecko/2008010203 SeaMonkey/2.0a1pre"
1.2.3.4 - - [05/Jan/2008:06:58:40 -0600] "GET /1.jpg HTTP/1.1" 403 - "-" "Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b2) Gecko/2007121120 Firefox/3.0b2"
1.2.3.4 - - [05/Jan/2008:07:00:09 -0600] "GET /1.jpg HTTP/1.1" 200 62205 "http://test.dlsgallery.com/" "Opera/9.25 (Windows NT 5.1; U; en)"
Comment 11 Vee 2008-03-22 09:44:17 PDT
I can confirm it works from Opera.
Comment 12 Dasa Paddock 2008-05-22 15:47:02 PDT
In my testing, only Firefox does not send the Referer, but this is true only for GET requests. Firefox DOES send the Referer for POST requests. I think it should send it for GET requests as well like the rest of the browsers.
Comment 13 Geoff Stearns 2008-06-28 15:07:34 PDT
Here's a test page to help show the problem:

http://dev.deconcept.com/referer_tester/

When clicking the "Push me" button in any browser other than Firefox, the referer is shown, but in Firefox it's always empty.
Comment 14 Matthias Versen [:Matti] 2008-09-03 11:27:36 PDT
*** Bug 452864 has been marked as a duplicate of this bug. ***
Comment 15 Dieter Menne 2008-11-11 07:41:02 PST
Safari 3.1.2 (525.2.1) has the same issue (=problem, bug, or whatever)
Comment 16 Matthias Versen [:Matti] 2009-02-25 17:25:43 PST
*** Bug 383708 has been marked as a duplicate of this bug. ***
Comment 17 Matthias Versen [:Matti] 2009-02-25 17:26:10 PST
*** Bug 443562 has been marked as a duplicate of this bug. ***
Comment 18 Matthias Versen [:Matti] 2009-02-25 17:29:21 PST
*** Bug 480195 has been marked as a duplicate of this bug. ***
Comment 19 Matthias Versen [:Matti] 2009-02-25 17:32:18 PST
from bug 383708:

>When loading urls from a browser plugin using NPN_Get/PostURLNotify, no Referer
>(referrer) header is added. 
>
>This does work in Safari, which uses the URL of the page embedding the plug-in,
>which in my opinion is correct.
Comment 20 Matthias Versen [:Matti] 2009-02-25 17:34:43 PST
*** Bug 409119 has been marked as a duplicate of this bug. ***
Comment 21 Matthias Versen [:Matti] 2009-02-25 17:39:56 PST
it seems that bug 157796 regressed
Comment 22 Tyler 2009-03-04 23:57:57 PST
Anyone looking at fixing this bug?
Comment 23 Andrew Hagen 2009-04-04 18:23:59 PDT
Regression as per comment 21.
Comment 24 Arnold 2009-07-09 02:18:42 PDT
this issue is not sloved in FF 3.5...
Comment 25 smoothkruger 2009-08-24 19:12:13 PDT
My question is, with the installed base of FireFox users spanning so many versions, some still at 1.0 will the bug, when fixed, be a recursive fix, or only for versions going forward. 

Otherwise, the only way to use hotlink protection it to tell people not to use a Gecko-based browser (the same bug is in Camino). That comes off badly for all parties
Comment 26 Sébastien Deleuze 2009-11-06 10:43:51 PST
Please fix this bug in 3.5.x, it is blocking for a lot of big companies working with Flash.
Comment 27 Matthias Versen [:Matti] 2009-12-02 10:40:05 PST
*** Bug 532364 has been marked as a duplicate of this bug. ***
Comment 28 Matthias Versen [:Matti] 2009-12-02 11:13:57 PST
*** Bug 532364 has been marked as a duplicate of this bug. ***
Comment 29 Kyle Huey [:khuey] (khuey@mozilla.com) 2009-12-15 14:52:52 PST
*** Bug 534976 has been marked as a duplicate of this bug. ***
Comment 30 Jo Hermans 2010-01-26 13:32:48 PST
*** Bug 542205 has been marked as a duplicate of this bug. ***
Comment 31 pranav 2010-01-27 04:13:25 PST
Is this bug going be to fixed??
Comment 32 Keli Hlodversson 2010-01-27 04:36:50 PST
Also note that this bug does not only affect the flash plugin. It affects any plugin using NPN_GetURLNotify or NPN_PostURLNotify.
Comment 33 Ray Greenwell 2010-07-08 14:16:23 PDT
*** Bug 577551 has been marked as a duplicate of this bug. ***
Comment 34 rui 2010-11-25 01:54:48 PST
Any news from this bug please ??? Still trying to find the solution....
Comment 35 N0n3 2011-01-10 09:44:17 PST
is it a joke ?? still no fix for that ??
how to setup correctly hotlink if FF don't do like others ??
Comment 36 alex da re 2011-01-10 12:45:22 PST
there's no other way than to ban completely firefox from your video sharing site. we did it with ours. users cannot use firefox to access the site
I think ff will follow the path of netscape. remember about that hot browser?
Comment 37 hensyoung 2011-01-11 21:10:50 PST
Three years, this SMALL bug which nobody of FF dev team cares will become NO bug.
Cause as the time goes by, HTML5 will make this bug no more exist.

A really wise way of fixing bug. Hahahaha...
Comment 38 Tim (fmdeveloper) 2011-03-06 14:10:49 PST
*** Bug 529214 has been marked as a duplicate of this bug. ***
Comment 39 Gaurav 2011-06-01 09:45:47 PDT
*** Bug 660854 has been marked as a duplicate of this bug. ***
Comment 40 rgreg 2011-07-12 13:06:03 PDT
3.5 years and bug dont solve?
Comment 41 admin 2011-08-16 22:02:59 PDT
wow pretty sad.  all browsers make it work except this one.
Comment 42 Bozo Clown 2011-09-08 11:54:00 PDT
Another vote to get this show stopper fixed.
Comment 43 Adam Taylor 2011-09-16 14:34:03 PDT
from: http://forums.mozillazine.org/viewtopic.php?t=617988
---------
(User grindlay posted):
Just a note with a workaround for cPanel/WHM hosted sites:
In the cPanel Hot Link Protection page,
Check the box that says "Allow direct requests (ie. entering the url to an image in your browser)"
For some reason (?) that will allow Flash movies to load in FF with Hot link protection active.
.htaccess file looks the same so clearly not solved by any wizardry in there.
--------
Comment 44 Shawn Carnell 2011-11-30 08:10:15 PST
+1 for fix.
Comment 45 mozilla 2011-11-30 08:51:19 PST
I just want to mark this date. I've been cc'd on this major bug for over 3 years and nothing has happened. I also stopped working on my project where this mattered, and also stopped using FF 2 years ago. So it's time to unsubscribe. Email me directly if it's ever fixed and I'll buy the author a bottle of champagne!
Comment 46 manu 2011-12-14 06:05:24 PST
+1 for fix
Comment 47 dgricci 2011-12-14 12:45:11 PST
+1 for fix
Comment 48 Cellier fabien [:fcellier] 2011-12-19 12:52:31 PST
Created attachment 582926 [details] [diff] [review]
Add referrer with http request

I'll try to ping someone on IRC in order to know if it's not in conflict with NPAPI before adding a reviewer.
Comment 49 Alice0775 White 2012-01-06 04:19:59 PST
(In reply to Cellier fabien [:tallion] from comment #48)
> Created attachment 582926 [details] [diff] [review]
> Add referrer with http request

FYI. The patch works properly in local win32 build.
Comment 50 Josh Aas 2012-01-10 21:56:23 PST
Comment on attachment 582926 [details] [diff] [review]
Add referrer with http request

Review of attachment 582926 [details] [diff] [review]:
-----------------------------------------------------------------

It looks like we do set a referrer on embedded streams (browser-initiated, data=) and I don't see why we can't set one on other plugin-initiated streams. Feedback+ on the concept, but I'd like to know Boris Zbarsky's thoughts on security.

::: dom/plugins/base/nsPluginHost.cpp
@@ +3094,5 @@
>    // deal with headers and post data
>    nsCOMPtr<nsIHttpChannel> httpChannel(do_QueryInterface(channel));
>    if (httpChannel) {
> +      
> +    rv = httpChannel->SetReferrer(doc->GetBaseURI().get());  

Why 'GetBaseURI' here? I think 'GetDocumentURI' might be better, it's what we already do for embedded plugin data streams.

@@ +3112,5 @@
>        NS_ASSERTION(uploadChannel, "http must support nsIUploadChannel");
>  
>        uploadChannel->SetUploadStream(aPostStream, EmptyCString(), -1);
>      }
> +    

Unnecessary whitespace change.

@@ +3117,4 @@
>      if (aHeadersData)
>        rv = AddHeadersToChannel(aHeadersData, aHeadersDataLen, httpChannel);
> +    
> +    NS_ENSURE_SUCCESS(rv,rv);

I'd prefer this be in the "if (aHeadersData)" scope, only running after the assignment.
Comment 51 Josh Aas 2012-01-10 21:57:39 PST
Comment on attachment 582926 [details] [diff] [review]
Add referrer with http request

Adding r- for the issues I outlined in my comments (leaving feedback+ on the concept).
Comment 52 Boris Zbarsky [:bz] 2012-01-10 22:11:36 PST
Comment on attachment 582926 [details] [diff] [review]
Add referrer with http request

> I think 'GetDocumentURI' might be better

Yes.  It would also have the virtue of not leaking, which the GetBaseURI() call there does (having to do the explicitly .get() to try to leak is supposed to protect you from doing that accidentally!).

I don't see any security problems with this; that part is fine.
Comment 53 Cellier fabien [:fcellier] 2012-01-11 10:16:50 PST
Created attachment 587744 [details] [diff] [review]
Add referrer with http request
Comment 55 Matt Brubeck (:mbrubeck) 2012-01-12 08:41:09 PST
https://hg.mozilla.org/mozilla-central/rev/65da0d7b408d
Comment 56 Thomas Ahlblom 2012-02-07 17:56:12 PST
*** Bug 724877 has been marked as a duplicate of this bug. ***
Comment 57 dindog 2012-02-13 07:04:25 PST
Well, this bug is meant to fixed some "deny" because of not sending referer in some flash.

But after it landed, many flash video also deny the request because it sending referer. (aside from the above depend on, i also have this two:

    Some youtube videos posted on fb not playing on Nightly
         http://forums.mozillazine.org/viewtopic.php?f=23&t=2424113
    the second video of this page:
         http://tieba.baidu.com/p/1405989753?pid=17126722962&cid=0#17126722962


And the I have a quick look to other browsers, none of IE and Chrome send referer in Flash request. It's kind of standard by custom. 

This is only landding on Nightly, and just about a month since it's landed, we got more than a half negative report than this bug 4 years history, affecting big site like Facebook. I'm quite sure there will be more *bug* report when Fx 12 ship with this patch.

So are this bug should be re-considered?
Comment 58 Boris Zbarsky [:bz] 2012-02-13 07:09:13 PST
Requesting tracking.  We need to figure out whether to back this out on branches.  

As far as other browsers go, do they never send Referer?  Or just not in POST requests (but do send with GET requests)?
Comment 59 dindog 2012-02-13 07:33:14 PST
(In reply to Boris Zbarsky (:bz) from comment #58)
> Requesting tracking.  We need to figure out whether to back this out on
> branches.  
> 
> As far as other browsers go, do they never send Referer?  Or just not in
> POST requests (but do send with GET requests)?

I'm sorry, I am wrong, Chrome does send referer, but not the referer of the page's URI, but seem like the the embed SRC... that would solved both of this bug and also the patch breaks site issue..
Comment 60 Boris Zbarsky [:bz] 2012-02-13 07:35:08 PST
Hmm.  Sending the plug-in itself as the referrer would make a lot of sense to me.
Comment 61 dindog 2012-02-13 07:47:31 PST
In the testcase, other browser sending is:
[http://dev.deconcept.com/referer_tester/referrer_test.swf]

Current Nightly is:
[http://dev.deconcept.com/referer_tester/]

Thing goes bad when embed plugin in other domain. It should reopen and let someone fix it.
Comment 62 Cellier fabien [:fcellier] 2012-02-13 07:49:46 PST
Yes, sorry for the delay :S. I will work on it next week, I'll try to use the dom element in order to find the url:

(My idea use https://hg.mozilla.org/projects/webcl/file/74c6ef4291c7/dom/plugins/base/nsPluginHost.cpp#l3086 ? could be a good solution).
Comment 63 Boris Zbarsky [:bz] 2012-02-13 08:00:52 PST
We should either open a new bug for that or use one of the bugs blocking this one, instead of doing the work here in a closed bug.
Comment 64 Benjamin Smedberg AWAY UNTIL 2-AUG-2016 [:bsmedberg] 2012-02-13 08:04:02 PST
I do not think that we should send the plugin as the referrer, because there are going to be lots of weird inconsistencies, but I'd love to be cc'ed on the newly-filed bug.
Comment 65 Ache 2012-02-13 08:46:50 PST
For the main .swf included by embed or object recent browsers (IE, Opera, Chrome) sends page referer, but for all materials which this .swf gets they send URL of this .swf.
Comment 66 Matthias Versen [:Matti] 2012-02-13 09:31:29 PST
We could use bug 724465. I will sort the mess with the depending bugs later and dupe them to bug 724465
Opera doesn't send a referer on post requests initiated by Plugins.i have a wireshark snippet in bug 724465 that confirms this.

This seems to be only a problem with IIS (bug 721311#c2) and not Apache
Comment 67 Cellier fabien [:fcellier] 2012-02-15 08:46:24 PST
>For the main .swf included by embed or object recent browsers (IE, Opera, Chrome) sends >page referer, but for all materials which this .swf gets they send URL of this .swf.
 

The first request is OK for all browser, the problem is after initialisation 

 Flash is one plugin but the change is directly in NPAPI and we don't  know if it's the material or the pluginInstance/runtime which want the  request, so referer could be irrevelant...

 So we can :
 - do nothing : In my knowledge, there is no standard for that, and having dom ref is more revelant (from my point of view)
 - accept change proposed by adobe
 (https://wiki.mozilla.org/NPAPI:GetRequestHeaders) AND the plugin update
 - create specific code for flash/silverlight...

 Furthermore, I don't understand the value of the material referer :
 It's not a security because we can easily use iframe or create a proxy
 (5 min with nodejs or python!). In fact you can also do the same with simple referer .
Comment 68 Boris Zbarsky [:bz] 2012-02-15 08:52:45 PST
This bug as filed is fixed.  Please do not reopen it unless you back the patch out.  Followup work should be in followup bugs...
Comment 69 Cellier fabien [:fcellier] 2012-02-15 08:56:38 PST
Ha ok, sorry for that.
Comment 70 Ache 2012-02-15 08:57:16 PST
>  Furthermore, I don't understand the value of the material referer :
>  It's not a security because we can easily use iframe or create a proxy
>  (5 min with nodejs or python!). In fact you can also do the same with
> simple referer .

Site_#1, flashplayer #1, #1.mp4 protected by referer in .htaccess from outside linking

Site_#2, flashplayer #2 attempts to play site_#1/#1.mp4, all browsers can't because of protection, excepting FF.
Comment 71 Benjamin Smedberg AWAY UNTIL 2-AUG-2016 [:bsmedberg] 2012-02-16 11:08:13 PST
Tests at https://hg.mozilla.org/integration/mozilla-inbound/rev/af615c25e502

Note that in bug 724465 this has now been disabled for POST requests.
Comment 72 Ed Morley [:emorley] 2012-02-17 05:22:00 PST
https://hg.mozilla.org/mozilla-central/rev/af615c25e502
Comment 73 dindog 2012-02-20 08:21:55 PST
I see all related bug are mark as dupe or resolved, just in case, the video playing issue remain, for Firefox sending wrong referer.
Comment 74 dindog 2012-02-20 08:33:10 PST
Created attachment 598889 [details]
this video won't play with wrong referer.
Comment 75 dindog 2012-02-20 08:39:16 PST
Sorry for the spam, the testcase is invalid, for some reason, attachment here don't send referer... you can test it here:

http://www.cnblogs.com/dindog/articles/2360745.html
Comment 76 Benjamin Smedberg AWAY UNTIL 2-AUG-2016 [:bsmedberg] 2012-02-21 05:51:53 PST
The difference in referer for GET posts is now filed as bug 729009.
Comment 77 Benjamin Smedberg AWAY UNTIL 2-AUG-2016 [:bsmedberg] 2012-03-07 11:26:11 PST
This was backed out of Firefox 12 because of changes that Josh has decided on in bug 729009 that we don't want to rush into late-aurora. https://hg.mozilla.org/releases/mozilla-aurora/rev/7e5412504995
Comment 78 Kevin Brosnan [:kbrosnan] 2012-03-21 09:56:29 PDT
*** Bug 737903 has been marked as a duplicate of this bug. ***
Comment 79 Ioana (away) 2012-05-10 09:44:10 PDT
Verified the issue as fixed on Firefox 13.0 beta 3 (BuildID: 20120509070325).
Comment 80 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-05-19 16:25:27 PDT
*** Bug 756831 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.