Send plugin src as plugin sub-request's referer

VERIFIED FIXED in Firefox 13

Status

()

Core
Plug-ins
--
major
VERIFIED FIXED
6 years ago
5 years ago

People

(Reporter: dindog, Assigned: Benjamin Smedberg)

Tracking

({regression})

12 Branch
mozilla13
regression
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox13+ verified)

Details

(Whiteboard: [qa!])

Attachments

(2 attachments)

(Reporter)

Description

6 years ago
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

6 years ago
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]
(Assignee)

Comment 2

6 years ago
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.
(Reporter)

Comment 3

6 years ago
(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?
> 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...
(Reporter)

Comment 5

6 years ago
I see Bug 724465 request landing for a aurora, if we change GET referer, for consistence, POST send nothing seem weird...
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

6 years ago
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

6 years ago
Forget my previous comment, Flash wasn't enabled. :|
(Reporter)

Comment 9

6 years ago
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.
(Assignee)

Comment 10

6 years ago
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?
(Assignee)

Updated

6 years ago
Assignee: nobody → benjamin
(Assignee)

Updated

6 years ago
tracking-firefox13: --- → +
(Assignee)

Comment 11

6 years ago
Created attachment 604503 [details] [diff] [review]
Preliminary, remove dead code, rev. 1
Attachment #604503 - Flags: review?
(Assignee)

Updated

6 years ago
Attachment #604503 - Flags: review? → review?(joshmoz)
(Assignee)

Comment 12

6 years ago
Created attachment 604517 [details] [diff] [review]
Part A - Make the Referer be the plugin source when available, rev. 1
Attachment #604517 - Flags: review?(joshmoz)

Updated

6 years ago
Attachment #604503 - Flags: review?(joshmoz) → review+

Comment 13

6 years ago
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.
Attachment #604517 - Flags: review?(joshmoz) → review+
(Assignee)

Comment 14

6 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/ac77925dc859
https://hg.mozilla.org/integration/mozilla-inbound/rev/6c949240ed79
Status: NEW → ASSIGNED
Whiteboard: landed on inbound
https://hg.mozilla.org/mozilla-central/rev/6c949240ed79
https://hg.mozilla.org/mozilla-central/rev/ac77925dc859
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Whiteboard: landed on inbound
Target Milestone: --- → mozilla13
(Assignee)

Updated

6 years ago
Flags: in-testsuite+

Updated

5 years ago
status-firefox13: --- → fixed
Whiteboard: [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
Status: RESOLVED → VERIFIED
status-firefox13: fixed → verified
Whiteboard: [qa+] → [qa!]
You need to log in before you can comment on or make changes to this bug.