[HTTPS-Everywhere] Continuing nits with FF 4.0b6 and Https-everywhere 0.2.3.development1

[pat flaherty]

> -------- Original Message --------
> Subject: 	FF 4.0b6 - nytimes.
> Date: 	Sun, 24 Oct 2010 10:07:42 -0700
> From: 	pat flaherty <patf at well.com>
> To: 	https-everywhere at eff.org
>
>
>
> Hi
>
> Https-Everywhere is largely working with FF 4.0b6 - thanx.
>
> One problem.  When I follow links from https://www.nytimes.com, they
> lead to blank pages.  For one, the target url is http and not https
> however I can't simply slip in the following 's' and have the link
> work.  I've deleted and recreated my FF profile several times which
> might seem to help at first but it's quickly back to the same behavior.
>
> secure.wikimedia.org and https://encrypted.google.com work fine in this
> regard and so that might suggest the nytimes rules files.
>
> How would I debug this?  Or well short of that, how does one turn on
> logging for the https-everywhere addon?  I see log features in the code
> but in spite of my fiddling around either I haven't turn it on correctly
> or I'm not looking in the correct place for the messages.
>
> pat
>
My nytimes link problem has gone away, at least for the moment.  I've 
recreated my profile now many times and I suspect that has something to 
do with it.

The following problem has been persistent.  I've researched it some and 
tracked it down to a fairly low level.

I use google to find specific wikipedia topics - I find this works 
better than Wikipedia's built-in search engine.  I'd google say:

wikipeida high performance computing

and the wikipeida page I want would typically be the first link.  Except 
with https-everywhere on, clicking the target would again (like nytimes 
previously) produce a blank page.

What I found is that the incorrect behavior happens only when I'm logged 
into google - when I'm not logged in the target page renders properly.  
I find that the URLs in the 2 cases differ:

Using FF 4's Web Console:

> SUCCESS
> Request URL:
>   
> https://encrypted.google.com/url?sa=T&source=web&cd=1&ved=0CBQQFjAA&url=http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FHigh-performance_computing&ei=bVDUTOyiO5OasAOsvY2PCw
>
>   Request Method:
>   GET
>
>   Status Code:
>   HTTP/1.1 204 No Content
>
>
> Request URL:
>   
> https://secure.wikimedia.org/wikipedia/en/wiki/High-performance_computing
>
>   Request Method:
>   GET
>
>   Status Code:
>   HTTP/1.1 200 OK
>
> FAIL
> Request URL:
>   
> https://encrypted.google.com/url?sa=t&source=web&cd=1&ved=0CBoQFjAA&url=http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FHigh-performance_computing&ei=l1DUTJs4haixA6PajI0L&usg=AFQjCNHGJdrIcFhxCdH_4EXE72GcnOJyoQ&sig2=zsHGXw4p8k-k0EUhWyqyzg
>
>   Request Method:
>   GET
>
>   Status Code:
>   HTTP/1.1 302 Found
>
> Request URL:
>   
> https://secure.wikimedia.org/wikipedia/en/wiki/High-performance_computing
>
>   Request Method:
>   GET
>
>   Status Code:
>   HTTP/1.0 404 Not Found

Comparing the two URLs, I find that in the failed case (logged into 
google) components, the payload of &ei= differs while &usg= and &sgi2= 
are present in the failed case, but not the successful.

pat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.eff.org/pipermail/https-everywhere/attachments/20101105/ca86ca98/attachment.html>