Opened 7 years ago

Last modified 22 months ago

#7851 assigned defect

XHR requests don't load when rewritten by HTTPS Everywhere (was: Rulesets affecting only XHR requests may not appear in the context menu.)

Reported by: pde Owned by: zyan
Priority: Medium Milestone:
Component: HTTPS Everywhere/EFF-HTTPS Everywhere Version:
Severity: Normal Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

HTTPS Everywhere has some fairly janky code for figuring out which window a request is associated with, so that it can populate the context menu correctly. The association process doesn't work with XHR requests made by script. Usually that doesn't matter. Occasionally, it does. For insance: #7503.

Child Tickets

TicketStatusOwnerSummaryComponent
#5952closedpde[CHROME] HTTPSEverywhere breaks Basecamp ajaxHTTPS Everywhere/EFF-HTTPS Everywhere
#7503closedpdethe verge doesn't show commentsHTTPS Everywhere/EFF-HTTPS Everywhere
#7627closedzyanComments on blogs.msdn.com don't showHTTPS Everywhere/EFF-HTTPS Everywhere
#9474closedzyan[9gag.com] HTTPS-Everywhere not redirecting GETs made after page loadHTTPS Everywhere/EFF-HTTPS Everywhere

Change History (5)

comment:1 Changed 6 years ago by zyan

Priority: minornormal
Summary: Rulesets affecting only XHR requests may not appear in the context menu.XHR requests don't load when rewritten by HTTPS Everywhere (was: Rulesets affecting only XHR requests may not appear in the context menu.)

It seems that HTTPS Everywhere, when it rewrites an XML HTTP request to HTTPS, prevents the xhr callback from executing (ex: AJAX-loaded comments don't show up on pages until the user disables the https everywhere rule for the URL that they're loading from). This is consistent with https://trac.torproject.org/projects/tor/ticket/9474 but is not specific to urls with redirect loops (since https://trac.torproject.org/projects/tor/ticket/7503 suffers from this bug as well).

This doesn't seem to apply to XHR URLs that were HTTPS in the first place, even if there is an applicable HTTPS Everywhere rule. 

Ex:

===

Got onChannelRedirect to https://9gag.com/?id=aLK9jLM&c=10
No window associated with request: http://9gag.com/?id=aLK9jLM&c=10
No window associated with request: https://9gag.com/?id=aLK9jLM&c=10
No applicable list rewriting https://9gag.com/?id=aLK9jLM&c=10
Processing https://9gag.com/?id=aLK9jLM&c=10
Potentially applicable rules for 9gag.com:

9gag

(Doesn't load)

===

No window associated with request: https://fbstatic-a.akamaihd.net/rsrc.php/v2/yy/r/C4Xx6CJRVz2.js
No applicable list rewriting https://fbstatic-a.akamaihd.net/rsrc.php/v2/yy/r/C4Xx6CJRVz2.js
Processing https://fbstatic-a.akamaihd.net/rsrc.php/v2/yy/r/C4Xx6CJRVz2.js
Potentially applicable rules for fbstatic-a.akamaihd.net:

Akamai

(Loads)

===

I am not sure whether this behavior is directly due to the fact that XHR requests are not associated with a specific window.

comment:2 Changed 6 years ago by zyan

Owner: changed from pde to zyan
Status: newassigned

comment:3 Changed 6 years ago by zyan

Oh, this appears to be at-least-sometimes an instance of same-origin policy violation, since different protocols are considered to be different origins.

The-Verge.xml in the current development branch is a good example of this:

As a result, if HTTPS everywhere is enabled and you go to the http:// page, the comments won't load. However, if you manually type in the https:// page, the comments load.

comment:4 Changed 5 years ago by zyan

Re: the original bug (that HTTPS Everywhere can't figure out which XHR requests are associated with a given window), I fixed this by QI'ing the loadContext from the notificationCallbacks.

comment:5 Changed 22 months ago by teor

Severity: Normal

Set all open tickets without a severity to "Normal"

Note: See TracTickets for help on using tickets.