Skip to content
This repository has been archived by the owner on Nov 6, 2023. It is now read-only.

Archive.is redirecting HTTPS to HTTP #5805

Closed
ghost opened this issue Jul 25, 2016 · 7 comments · Fixed by #5886
Closed

Archive.is redirecting HTTPS to HTTP #5805

ghost opened this issue Jul 25, 2016 · 7 comments · Fixed by #5886

Comments

@ghost
Copy link

ghost commented Jul 25, 2016

It seems archive.is has started redirecting HTTPS requests to HTTP (with an annoying 10-second delay). For example: https://archive.is/2VUZ (though I can't consistently reproduce this 100% of the time). Not sure how to disable a rule (just comment it out, or something else?) so I'm just opening an issue.

@ghost ghost changed the title Archive.is started redirecting HTTPS to HTTP Archive.is redirecting HTTPS to HTTP Jul 25, 2016
@fuglede
Copy link
Contributor

fuglede commented Jul 26, 2016

I tried refreshing and waiting for 10 seconds quite a few times in both Firefox and Chromium and did not manage to reproduce the issue.

What goes wrong with respect to HTTPS Everywhere? If the site provided a single redirect, I would expect it to simple re-secure the connection (with an additional redirect).

Edit: And to answer your question, to disable a ruleset completely (which is often not completely necessary), the solution would to add default_off="explanation of why" to the ruleset root XML element.

@ghost
Copy link
Author

ghost commented Jul 26, 2016

Sorry, I forgot to mention that when it happens, it just shows a white page saying "redirecting to http://archive.is/2VUZ in 10 seconds", and when that elapses, HTTPS Everywhere redirects back to HTTPS and it starts over...

@ghost
Copy link
Author

ghost commented Jul 26, 2016

OK, it seems it only does this if the referrer is Wikipedia (telling RefControl to forge it as https://en.wikipedia.org/ works).

@ghost
Copy link
Author

ghost commented Jul 26, 2016

Or maybe not, it may be some weird A/B testing. After disabling the referrer spoofing I still got redirected a few times and then it stopped, and now different message: "Redirecting to https://archive.today/2VUZ in 10 seconds".

@fuglede
Copy link
Contributor

fuglede commented Jul 26, 2016

Yeah, I see what you are saying:

$ curl -I http://archive.is/test
HTTP/1.1 200 OK
Refresh: 12;url=http://archive.today/test

$ curl -I https://archive.is/test
HTTP/1.1 200 OK
Refresh: 12;url=https://archive.today/test

$ curl -I http://archive.today/test
HTTP/1.1 302 Found
Location: //archive.is/test

$ curl -I https://archive.today/test
HTTP/1.1 302 Found
Location: //archive.is/test

Now I'm wondering why Firefox isn't picking this up.

In any case, as I'm reading those responses, you would also see that issue without HTTPS Everywhere -- what happens if you disable the ruleset?

@fuglede
Copy link
Contributor

fuglede commented Jul 26, 2016

And it is pretty random indeed;

$ curl -Is https://archive.is/2VUZ | grep Refresh
$ curl -Is https://archive.is/2VUZ | grep Refresh
Refresh: 12;url=https://archive.today/2VUZ

@fuglede
Copy link
Contributor

fuglede commented Jul 28, 2016

I contacted the webmaster of the site, and it seems that the behaviour above is due to a bot request throttling mechanism (which could also explain why I was only able to reproduce after testing for a while).

fuglede added a commit to fuglede/https-everywhere that referenced this issue Jul 31, 2016
After having had a couple of different issues with this ruleset, cf. in particular

    EFForg#5805 and
    EFForg#4075

I prompted the webmaster for what would be a proper solution moving forwards. On their request, this avoids redirecting anything to https://archive.is/ but ensures that the relevant connections are still upgrading by using archive.fo instead.
@J0WI J0WI closed this as completed in #5886 Aug 2, 2016
J0WI pushed a commit that referenced this issue Aug 2, 2016
* [Archive.is] Update ruleset

After having had a couple of different issues with this ruleset, cf. in particular

    #5805 and
    #4075

I prompted the webmaster for what would be a proper solution moving forwards. On their request, this avoids redirecting anything to https://archive.is/ but ensures that the relevant connections are still upgrading by using archive.fo instead.

* [Archive.is] Update comment
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant