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

[Loic J. Duros]

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
>
>