You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Nov 6, 2023. It is now read-only.
Repository navigation
This repository was archived by the owner on Nov 6, 2023. It is now read-only.
When i try to connect to https://rockfile.eu/al3ehe8at0yx.html with firefox and https everywhere enable
i got an infinite loop from Cloudflare with the massage
"Checking your browser before accessing rockfile.eu.
This process is automatic. Your browser will redirect to your requested content shortly.
Please allow up to 5 seconds…"
If i disable https everywhere i don't have infinite loop and all works.
I get the same redirect loop. It looks like it happens because the site tries to redirect that page to http but HTTPS Everywhere tries to rewrite it to https so you get an infinite loop. I tried the following links with the ruleset disabled:
The first two redirected to http and the secure subdomain doesn't seem to cover that part of the site. Since other parts of the site seem to work fine with the ruleset enabled, it seems like an exclusion is what is needed to solve the problem.
To me it seems like there are two possible scenarios here:
All download pages on the site redirect to http
Active download pages support https while download pages with no file available redirect to http
Both situations could be solved with an exclusion like this:
This exclusion seems to work for the download pages I've found. The exclusion completely solves the problem for scenario 1 but has the unfortunate side-effect of not covering active download pages if scenario 2 is what's happening. But even if scenario 2 is what is actually happening, there is no way for a ruleset to be written to cover that scenario. So it seems like the exclusion is the solution regardless.
Also with exclusion (https everywhere 5.2.16 and rule rockfile partial) i have the problem of infinite loop.
Try http://rockfile.eu/m2mrn5o6mbz9.html
Is there a solution?
That's weird. I'm getting the infinite loop problem with that page too. The exclusion regex matches that URL so I'm stumped about why this is still happening. @Bisaloo@J0WI@cschanaj do any of you have an idea as to why this is still happening? My only idea for a solution is changing the ruleset to default_off
Activity
bup4gr commentedon Apr 8, 2017
Same problem with tor browser 6.5.1 and htts ewerywhere 5.2.14
Is there a solution?
afarrow commentedon Apr 21, 2017
I get the same redirect loop. It looks like it happens because the site tries to redirect that page to http but HTTPS Everywhere tries to rewrite it to https so you get an infinite loop. I tried the following links with the ruleset disabled:
The first two redirected to http and the secure subdomain doesn't seem to cover that part of the site. Since other parts of the site seem to work fine with the ruleset enabled, it seems like an exclusion is what is needed to solve the problem.
To me it seems like there are two possible scenarios here:
Both situations could be solved with an exclusion like this:
This exclusion seems to work for the download pages I've found. The exclusion completely solves the problem for scenario 1 but has the unfortunate side-effect of not covering active download pages if scenario 2 is what's happening. But even if scenario 2 is what is actually happening, there is no way for a ruleset to be written to cover that scenario. So it seems like the exclusion is the solution regardless.
bup4gr commentedon May 14, 2017
Also with exclusion (https everywhere 5.2.16 and rule rockfile partial) i have the problem of infinite loop.
Try http://rockfile.eu/m2mrn5o6mbz9.html
Is there a solution?
afarrow commentedon May 14, 2017
That's weird. I'm getting the infinite loop problem with that page too. The exclusion regex matches that URL so I'm stumped about why this is still happening. @Bisaloo @J0WI @cschanaj do any of you have an idea as to why this is still happening? My only idea for a solution is changing the ruleset to
default_off