User Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0a2) Gecko/20120205 Firefox/12.0a2 Build ID: 20120205042013 Steps to reproduce: After updating to 12a2 from 11a2: Tried to log into my Sip Sorcery account via their Silverlight portal (http://www.sipsorcery.com/mainsite/Home/Portal) Actual results: The dot in the upper left corner turned red (should be green) I entered my login and password and got an error logging in Expected results: The dot initially should be green and I should be able to log in.

It works if network.http.sendRefererHeader set to 0 or 1.

Yes! I've changed it to 1 and it works again. Thank you.

It looks like a bug in the site if just disabling the referer of the embed object makes it work. Can someone contact them, maybe Igor ?

There is nothing wrong with the site. The same problem had been reported a bit earlier with another site. And I found a new one:http://services.biathlonresults.com/Live.aspx (works fine with 1) Everything that has Silverlight in it looks broken.

I used http://services.biathlonresults.com/Live.aspx for testing and I can confirm this issue with Seamonkey trunk on win32. Seamonkey gets a HTTP 400 "Bad Request (Invalid Header Name)" after a HTTP post that includes the referer. I'm not sure why it shouldn't be valid to send the referer here but Opera11.6 doesn't send a referer for Post requests initiated by the Plugin. I bet that removing the referer from the post request will fix all regressions from bug 410904 I will attach a wireshark snippet that shows the post requests from FF10,SM trunk and Opera11.60 I'm requesting tracking because this seems to break many silverlight pages. Look at the depending bugs of bug 410904

Josh, I think we should disable referrers for plugin POSTs to fix this issue. Do you disagree?

https://hg.mozilla.org/integration/mozilla-inbound/rev/cabba131ae45 https://hg.mozilla.org/integration/mozilla-inbound/rev/af615c25e502

https://hg.mozilla.org/mozilla-central/rev/cabba131ae45 https://hg.mozilla.org/mozilla-central/rev/af615c25e502

Comment on attachment 597831 [details] [diff] [review] Don't send Referer with plugin POST requests, rev. 1 This patch reverts to the prior behavior for POST requests only, and should be fairly safe.

this bug fixed don't solve all problem, if you ever test... Most of the video playing problem is GET, not POST, why not follow other browser send the plugin itself as referer? That solve all issue for once and all.

That's not what this bug is about. If you need to file a bug specifically about the GET issue, please do it separately with a testcase/testcase URL.

Comment on attachment 597831 [details] [diff] [review] Don't send Referer with plugin POST requests, rev. 1 [Triage Comment] Fixes silverlight breakage and deemed low risk - approved for Aurora 12.

Landing on Aurora 12 ping.

(In reply to Alex Keybl [:akeybl] from comment #22) > Landing on Aurora 12 ping. When it will land on Aurora 12?

> When it will land on Aurora 12? (echo) This also breaks some Japanese video sites: http://streaming.yahoo.co.jp/guide/sample/?b=300 http://www.dmm.com/digital/-/player/=/action=sample/ We hope this would get fixed soon.

Bug 410904 was backed out of Aurora (FF12).

(In reply to Benjamin Smedberg [:bsmedberg] from comment #26) > Bug 410904 was backed out of Aurora (FF12). Confirmed those videos can now play w/o changing the referer pref.

Comment on attachment 597831 [details] [diff] [review] Don't send Referer with plugin POST requests, rev. 1 clearing approval per bsmedberg's "gecko 12--> unaffected" comment and that this never landed there

Comment on attachment 597832 [details] [diff] [review] Test Did you mean to include contents of test_pluginstream_referer.html/sjs? and/or did this patch land?

Pool Live Tour not working, bug 732371 on Firefox 12 beta 1

Bug 410904 was backed out of Firefox 12 train, so it cannot be the cause of this bug. Please reopen the other bug which is probably not a duplicate.

http://www.sipsorcery.com/mainsite/Home/Portal https://indexes.nasdaqomx.com/ https://amarantisnoord.swp.nl/ are working fine, no errors/crashes occur. This is verified fixed on FF 13b2: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20100101 Firefox/13.0 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20100101 Firefox/13.0