729009 - Send plugin src as plugin sub-request's referer

Status: VERIFIED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[dindog]

This is what other browsers do. After Bug 410904 patch, it send document's URI, which will meet some error, especially for the plugin embed in a different domain page.

You can see the different referer in the testcase of Bug 410904:
http://dev.deconcept.com/referer_tester/

This is a embed flash video which only firefox fail to play:
http://www.cnblogs.com/dindog/articles/2360745.html

All bug depend on Bug 410904 is marked fixed or dupe, decided to file a new one.

Comment 1

[Alice0775 White]

confirmed
http://hg.mozilla.org/mozilla-central/rev/0a7410527788
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/13.0 Firefox/13.0a1 ID:20120220074932

Error in Web console:
[18:11:59.101] GET http://vxml.56.com/json/NjI4MTEzMzg/?src=out [HTTP/1.1 403 Forbidden 590ms]

Comment 2

[Benjamin Smedberg]

Obviously the behavior isn't specified, but I don't believe that sending the plugin URL is the correct behavior: for the most part plugins don't introduce a new browsing context.

Comment 3

[dindog]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #2)
> Obviously the behavior isn't specified, but I don't believe that sending the
> plugin URL is the correct behavior: for the most part plugins don't
> introduce a new browsing context.

It is not specified, but Firefox is eccentric in all these years, hoping Bug 410904 fixed that, but now only make it even weird than before.

Just check Opera using the test case above, same as IE and Chrome:
 [http://dev.deconcept.com/referer_tester/referrer_test.swf]

Simple decision, heh?

Comment 4

[Boris Zbarsky [:bzbarsky]]

> for the most part plugins don't introduce a new browsing context.

Neither do SVG resource documents or stylesheets, yet I'm pretty sure that @import in a stylesheet sends the stylesheet URI as the referrer and that resources loaded from SVG resource documents send the resource doc URI as the referrer.

Actually, CSS background images and the like also use the stylesheet as the referrer.  See bug 249168.

For what it's worth, I think sending the plug-in URI as the referrer for requests the plug-in makes is perfectly reasonable...

Comment 5

[dindog]

I see Bug 724465 request landing for a aurora, if we change GET referer, for consistence, POST send nothing seem weird...

Comment 6

[Emanuel Hoogeveen [:ehoogeveen]]

I hope a consensus is reached here soon. This change in behavior has unfortunately broken the 'embedded highlights' functionality of one of my favorite websites, live.lordkat.com, and I would hate to see one or even two releases of Firefox stay incompatible with it (if this turns into an evangelism issue it's probably twitch.tv that would have to be contacted). I have set network.http.sendRefererHeader = 1 as a workaround, but I doubt most users will find this option.

Comment 7

[Loic]

Another example to test: http://www.musicme.com/#/Lana-Del-Rey/
It's a website similar to iTunes or Deezer to buy/download music.

If you use FF10, the Flash player is visible on the right:
http://i.imgur.com/LTc2s.jpg

If you use FF13, the Flash player is not visible and the website asks you to update your Flash player:
http://i.imgur.com/ASOXP.jpg

network.http.sendRefererHeader = 1 doesn't work as workaround in FF13.

Comment 8

[Loic]

Forget my previous comment, Flash wasn't enabled. :|

Comment 9

[dindog]

Base on other browsers actual behavior and comment 4, isn't the choice  obviously?

Because of Bug 410904 and Bug 724465, some plugin will behave different from previous versions of Fx and also other browsers.

Less than two weeks, current nightly will move to aurora, more extra review needed by then.

Comment 10

[Benjamin Smedberg]

Josh decided that we should send the plugin src as the referer (when there is one). However, when trying to implement this I discovered that nsNPAPIPluginInstance::mURI/SetURI/GetURI are dead code, and so it doesn't appear that the plugin instance actually knows its URI after its finished delivering the initial stream.

Josh, is there an alternate way of knowing the plugin src from the instanceowner or something? If not, should I be resurrecting SetURI and make it correct?

Comment 11

[Benjamin Smedberg]

Attachment: Preliminary, remove dead code, rev. 1

Comment 12

[Benjamin Smedberg]

Attachment: Part A - Make the Referer be the plugin source when available, rev. 1

Comment 13

[Josh Aas]

Comment on attachment 604517 [details] [diff] [review]
Part A - Make the Referer be the plugin source when available, rev. 1

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

::: content/base/src/nsObjectLoadingContent.cpp
@@ +2070,5 @@
>    return rv;
>  }
>  
> +NS_IMETHODIMP
> +nsObjectLoadingContent::GetSrcuri(nsIURI** aURI)

Can we capitalize URI in the method name? Looks pretty odd without it.

Comment 14

[Benjamin Smedberg]

https://hg.mozilla.org/integration/mozilla-inbound/rev/ac77925dc859
https://hg.mozilla.org/integration/mozilla-inbound/rev/6c949240ed79

Comment 15

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

https://hg.mozilla.org/mozilla-central/rev/6c949240ed79
https://hg.mozilla.org/mozilla-central/rev/ac77925dc859

Comment 16

[Simona Badau, Desktop QA]

Verified that the embed flash video from the Description plays on Firefox 13 beta 3.
 
Verified as fixed on Windows 7, Ubuntu 12.04 and Mac OS X 10.6:
Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20100101 Firefox/13.0
Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20100101 Firefox/13.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20100101 Firefox/13.0