[HTTPS-Everywhere] https-everywhere bug with channels not attached to a window

[Loic J. Duros]

Thought I'd mention this in case anyone is having the same issues: 
Building the extension from the git repository completely addresses the 
issue. All rewritten URIs are properly being notified.

Thanks much,


On 05/13/2012 05:17 PM, Loic J. Duros wrote:
> I've got this working by using the observer pattern and notifying the 
> object that does the xhr... No big issue. However it still seems that 
> you get no https-everywhere-uri-rewrite notification for many 
> rewrites, including those from Google Ads.
>
> Here is an example of a site with this problem: http://lxer.com/
> another one is: http://fsdaily.com
>
> Does anybody know examples of sites that use JavaScript files with 
> urls that are rewritten and for which the notification is triggered?
>
> Thanks,
>
> Loic
>
> On 05/12/2012 06:31 PM, Loic J. Duros wrote:
>> On 05/08/2012 05:11 PM, Peter Eckersley wrote:
>>> That's not the reason HTTPS Everywhere is messing up your XHR.  The
>>> real problem is this bug:
>>>
>>> https://trac.torproject.org/projects/tor/ticket/3190
>>>
>>> and this one, which is preventing a sensible workaround:
>>>
>>> https://trac.torproject.org/projects/tor/ticket/5682
>>>
>>> I was hoping that Justin Samuel could take a look at that second 
>>> bug, but he
>>> told me that he's going to be prohibitively busy for the next few 
>>> months, so
>>> someone else is going to need to wade in and fix #5682.
>>
>> Ah, got it. Thanks for pointing out that the issue is the same. I'm 
>> able to see that the https-everywhere-uri-rewrite notification is 
>> triggered on some sites, but I don't have yet a clear idea how I 
>> would update my xhr after the channel has been replaced. Justin 
>> Samuel in RequestPolicy checks with the content policy "shouldLoad" 
>> if the current url has a mapping, which would show it has been 
>> rewritten. However, in the case of the xhr, my guess is that I'd have 
>> to update the original nsIHttpChannel? Not sure how to do this yet, 
>> but in any case, many thanks for your help.
>>
>> var req = Cc["@mozilla.org/xmlextras/xmlhttprequest;1"]
>>     .createInstance(Ci.nsIXMLHttpRequest);
>>
>> req.open('GET', 
>> 'http://pagead2.googlesyndication.com/pagead/show_ads.js', true);
>>
>> req.send(null);
>>
>> req.onreadystatechange = function (evt) {
>>     if (req.readyState == 4 && req.status == 200) {
>>         // do something with req.responseText
>>       }
>> };
>>
>>>
>>> On Tue, May 08, 2012 at 02:25:17PM -0400, Loic J. Duros wrote:
>>>> Hello:
>>>>
>>>> I'd like to report an issue with Https Everywhere. I'm not sure if I
>>>> can report it to a bug tracker directly, and whether this can be
>>>> reproduced for any url switched from http to https.
>>>>
>>>> Https-Everywhere seems to assume that there is a DOM window attached
>>>> to all channels, and it fails (returning null) when that's not the
>>>> case. It will log "DOMWindow exploded" when that's the case.
>>>>
>>>> To reproduce this issue, you must make an xhr request directly from
>>>> code that is not attached to a window. This is common practice, and
>>>> is the case if an extension is performing a request to fetch data
>>>> without a DOM window using nsIXMLHttpRequest:
>>>> https://developer.mozilla.org/en/nsIXMLHttpRequest
>>>>
>>>> Attempting to perform an xhr request on such a url as:
>>>> http://pagead2.googlesyndication.com/pagead/show_ads.js will never
>>>> get through:
>>>>
>>>>          var req = Cc["@mozilla.org/xmlextras/xmlhttprequest;1"]
>>>>          .createInstance(Ci.nsIXMLHttpRequest);
>>>>
>>>>          // request made synchronous for the sake of the demo
>>>>          req.open('GET',
>>>> 'http://pagead2.googlesyndication.com/pagead/show_ads.js', false);
>>>>          req.send(null);
>>>>
>>>> My extension (GNU LibreJS) relies on such XHR requests to analyze
>>>> JavaScript before a response even gets parsed, and as a temporary
>>>> fix I've added a 15 second time out to cancel the piece of code that
>>>> analyzes the script, since it's not being returned at all. Since we
>>>> are planning on adding LibreJS to GNU IceCat and that GNU IceCat
>>>> runs https-everywhere, it is for us an important issue, and if you
>>>> know of a potential way to address this, it would be very helpful!
>>>> :-)
>>>>
>>>> Thanks,
>>>>
>>>> Loic
>>>>
>>>>
>>>> _______________________________________________
>>>> HTTPS-everywhere mailing list
>>>> HTTPS-everywhere at mail1.eff.org
>>>> https://mail1.eff.org/mailman/listinfo/https-everywhere
>>
>>
>> _______________________________________________
>> HTTPS-everywhere mailing list
>> HTTPS-everywhere at mail1.eff.org
>> https://mail1.eff.org/mailman/listinfo/https-everywhere
>>
>>
>
>
> _______________________________________________
> HTTPS-everywhere mailing list
> HTTPS-everywhere at mail1.eff.org
> https://mail1.eff.org/mailman/listinfo/https-everywhere
>
>