Opened 7 years ago

Last modified 23 months ago

#6486 reopened enhancement

Offer option to disable redirection loop detection

Reported by: grarpamp Owned by: pde
Priority: Low Milestone:
Component: HTTPS Everywhere/EFF-HTTPS Everywhere Version:
Severity: Normal Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Need a config option to prevent falling back to http.
Fallback makes writing and debugging rules harder
when the browser doesn't perform whatever the native
action would be for requests that do not work, such as:

retry, stop with browser or server error message, etc...

and instead forges on ahead forevermore.

Also, users often use their own credentials when writing
and testing rules, so fallback to http can be hazardous
to them, their accounts, etc. Noted in re: #6485

Child Tickets

Change History (9)

comment:1 Changed 7 years ago by pde

By "fallback to http" are you talking about detecting pages that redirect https->http, thereby creating a loop? Or are you talking about blocking all http requests, so that you can tell if you've "covered everything"?

comment:2 Changed 7 years ago by grarpamp

watch the firefox "web console" and "error console".
definitely not your second sentence.
i think i was referring to some form of your first. re: the error console.
i think if a rule rewrote http to https, but the server
didn't like or respond to https, https-e would just fall back to http.
well, that's great for feeding the user a working web site,
whether https or not. but not great for rule writers because they
need to see how the https failed.
ie: exactly as if they'd entered the https url directly on a
browser without https-e installed... you'll see a browser timeout,
or a server timeout, or some server error.
as for a loop, i think i saw some 302 redirection loops, that
would eventually fall back, not sure.
but it was the automatic and permanent switch back to http that was the problem.

comment:3 Changed 7 years ago by pde

Resolution: invalid
Status: newclosed

The only kind of fallback to HTTP we currently do is detection of 301/302 loops.

We need to figure out a way to detect loops caused by JavaScript loops, but we currently don't have one.

Unless you're saying that you want a way to disable the 301/302 loop detection, I'm going to mark this as invalid.

comment:4 Changed 7 years ago by grarpamp

Resolution: invalid
Status: closedreopened

This ticket does not concern javascript content loops, it concerns protocol loops.

Unless...

Yes, thought this was answered on 2012-09-15.
Again, if browser is fed an http uri, https-e remaps it to https and sends it to server, and then if the https server returns protocol error, or plain doesn't respond, I don't want https-e hiding that server message or browser timeout from me (and possibly also falling back).
And if the server protocol 302's it back to http, I don't want https-e taking that 302 to http directive, remapping it again to https, sending it again, looping around with that for a while till finally giving up and using the server's 302 to http, and staying http thereafter.

So an option to disable the fallback after loop detected, aka: don't use http ever.
And an option to just quit that uri on error or timeout, aka: show me.

comment:5 Changed 7 years ago by grarpamp

It also seems this would be most useful on, at minimum, a per rule, most specific first, basis since sites may still be usable whether or not a particular uri worked or is handled a certain way.

comment:6 in reply to:  4 Changed 7 years ago by pde

Priority: normalminor

Replying to grarpamp:

Again, if browser is fed an http uri, https-e remaps it to https and sends it to server, and then if the https server returns protocol error, or plain doesn't respond, I don't want https-e hiding that server message or browser timeout from me (and possibly also falling back).

It shouldn't do either of these things. Do you have an example?

And if the server protocol 302's it back to http, I don't want https-e taking that 302 to http directive, remapping it again to https, sending it again, looping around with that for a while till finally giving up and using the server's 302 to http, and staying http thereafter.

HTTPS Everywhere does do this. If the site won't keep your data secure, the site won't keep your data secure, and HTTPS isn't going to help. Our default philosophy is to maximize security without breaking websites.

So an option to disable the fallback after loop detected, aka: don't use http ever.
And an option to just quit that uri on error or timeout, aka: show me.

Want to write the patch? It should be an about:config setting, rather than anything in the UI, and the place you want to patch is here (excuse the whacky newlines, they're from the NoScript source).

comment:7 Changed 7 years ago by pde

Summary: Need non-fallback to http optionOffer option to disable redirection loop detection

comment:8 Changed 7 years ago by pde

Type: defectenhancement

comment:9 Changed 23 months ago by teor

Severity: Normal

Set all open tickets without a severity to "Normal"

Note: See TracTickets for help on using tickets.