Skip to content
Snippets Groups Projects

Offer option to disable redirection loop detection

    • Closed (moved) Issue created by grarpamp @grarpamp

    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 (moved)

    To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information

    Child items 0

    • No child items are currently assigned. Use child items to break down this issue into smaller parts.

    Activity

    • grarpamp added component::https everywhere/eff-https everywhere owner::pde priority::low severity::normal status::reopened type::enhancement labels

      added component::https everywhere/eff-https everywhere owner::pde priority::low severity::normal status::reopened type::enhancement labels

    • P
      Peter Eckersley @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"?

    • G
      grarpamp @grarpamp ·
      Author

      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.

    • P
      Peter Eckersley @pde ·

      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.

      Trac:
      Status: new to closed
      Resolution: N/A to invalid

    • G
      grarpamp @grarpamp ·
      Author

      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.

      Trac:
      Resolution: invalid to N/A
      Status: closed to reopened

    • G
      grarpamp @grarpamp ·
      Author

      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.

    • P
      Peter Eckersley @pde ·

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

      Trac:
      Priority: normal to minor

    • P
      Peter Eckersley @pde ·

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

    • P
      Peter Eckersley @pde ·

      Trac:
      Type: defect to enhancement

    • T
      teor @teor ·

      Set all open tickets without a severity to "Normal"

      Trac:
      Severity: N/A to Normal

    • Trac moved to tpo/applications/https-everywhere-eff#6486 (closed)

      moved to tpo/applications/https-everywhere-eff#6486 (closed)

    Please register or sign in to reply