thenation.com has javascript that causes duplicate requests which result in missing destinations in RP menu

[jsamuel]

imported trac ticket
created: 2010-02-08 07:08:52
reporter: justin

This page:

http://www.thenation.com/doc/20100222/lessig

performs more than one request to one of its stylesheets:

http://www.thenation.com/css/screen/main.css

which causes a problem because that stylesheet requests third-party content:

http://s3.amazonaws.com/thenation/css/core.css

and the information about the blocked/allowed third-party request is lost when the second request is made. The second request doesn't make the same third-party content requests (probably because the content is already cached).

The reason the information about the blocked/allowed requests that originate from http://www.thenation.com/css/screen/main.css is lost when http://www.thenation.com/css/screen/main.css itself is requested again is that this is how !RequestPolicy decides whether to clear its old information about an origin urls requests: when that origin itself is requested again, all previous information about the origin's blocked/allowed request destinations is cleared.

My testing so far seems to indicate that the duplicate request may be the result of javascript running on thenation.com. When I have thenation.com blocked with !NoScript, then the duplicate request never seems to happen (from what I can tell) and I always get amazonaws.com as a blocked/allowed destination in the RP menu. However, when thenation.com is allowed with !NoScript, many additional requests are made (including to different destinations) and sometimes the duplicate request to /css/screen/main.css is performed, causing amazonaws.com to not show up in the menu.

I'm not sure at the moment how to solve this. I'm inclined to say it's just a bug in a website and because it seems to be an uncommon bug (only this one website is known to have it), there's no need to try to work around it. Maybe the best thing to do would be to track down the javascript that's the culprit, fix it for them, and send the web developers of thenation.com a patch (which wouldn't just help RP but would actually improve page load time because there's an unnecessary request being made).

[ghost]

Not totally sure it is the same problem, but on http://www.mojang.com/ they have their title banner as a CSS "background-image". The CSS file is located on CloudFront.net, but the banner picture is back on Mojang.com.

• The banner DOES NOT appear when authorizing mojang.com => cloudfront.net.
• The banner DOES NOT appear when allowing all requests from mojang.com.
• The banner DOES appear when temporarily allowing all requests.
• There is no mention to cloudfront.net in the "Other origins within this page" menu (is this meant for this kind of cases?).

To make the banner appear without effectively disabling RequestPolicy completely, I have to authorize the reverse direction, cloudfront.net => mojang.com manually (well, the first time going to the CSS file, it did show mojang.com as a destination, but not afterward).

Thanks to anyone who may work on this issue.

[ghost]

Just had another similar issue with YouTube videos embedded in http://wiki.teamfortress.com/wiki/Rocket_Launcher#Demonstration and http://www.teamfortress.com/saxxyawards/?cat=action ... had to authorize notably youtube.com => youtube.googleapis.com manually (it was not shown in the list of blocked domains, and there was nothing in the "Other origins within this page" on the wiki, and only youtube.com => yimg.com on the second link, which I had already authorized).

Both pages only reference youtube.com link, so I suppose in this case, the problem is that the link is being redirected to another domain in the background, and RequestPolicy does not pick this up for the list of blocked domains...

For this sort of problems (and to check precisely what is requested and blocked very easily), the request log included in RequestPolicy ("Show Request Log", under "Preferences" in the addonbar icon menu) is very useful. It would be nice if there was a right-click menu entry in this request log to authorize a blocked download though, instead of only being able to copy the source and destination separately, to add them manually in the Preference window...

To summarize both of my cases, which are not picked up in the list of blocked domains (both the main list and the list in "Other origins within this page"):

1) HTML on domain 1 => CSS file on domain 2 => background-image references a file back on domain 1 but the file is blocked without notice

2) Embedded youtube.com link => youtube.com wants to redirect it to youtube.googleapis.com but is blocked without notice

(Sorry for hijacking this report if it is not the same problem :3)

[Edit: Actually it still does not work for the second link (http://www.teamfortress.com/saxxyawards/?cat=action), and I have nothing else being blocked in the request log :/ But the Flash/YouTube UI do appear... but if I right-click and get the video URL, it gives me "https://www.youtube.com/feature=player_embedded"... the same videos work in Opera, so I don't suppose it is a website issue, although there may be some user agent detection issue... allowing all requests with RequestPolicy and NoScript does not change anything... may well be something else...]

[Edit2: 'was some problem with HTTPS Everywhere... everything works now...]