#1505 how to redirect HTTPS to HTTP


I am using Privoxy 3.0.17 on Linux with Firefox.
I would like to redirect a certain webpage's HTTPS requests to HTTP so I can inspect the contents of the requests.
I have tried the following in user.action:

{ +redirect{s@^https://@http://@} }

... which produces the following in the Privoxy logfile:
Redirect: pcrs command "s@^https://@http://@" didn't change "www.example.com:443".

I then tried the following (then I tried it again without the backslashes):

{ +redirect{s@\:443$@\:80@} }

... which didn't seem to do anything (no logfile entries).

I have found https://sourceforge.net/tracker/index.php?func=detail&aid=2899297&group_id=11118&atid=111118
which mentions stunnel. Is stunnel the recommended way to do what I'm trying to do, or is there a way in Privoxy?

Thanks for your help.


  • Fabian Keil

    Fabian Keil - 2012-08-08
    • assigned_to: nobody --> fabiankeil
    • status: open --> pending
  • Fabian Keil

    Fabian Keil - 2012-08-08

    Your first +redirect{} doesn't work because CONNECT requests (which the browser uses to tunnel https:// connections) do not contain the protocol as can also be seen in the "Redirect:" message you got.

    Your second +redirect{} will not work for CONNECT requests because the result lacks the protocol.

    The error message you should have gotten for it looks like this:
    09:44:41.843 003 Error: pcrs command "s@\:443$@\:80@" changed "www.example.com:443" to "www.example.com:80" (1 hit), but the result doesn't look like a valid URL and will be ignored.

    The colon isn't special, so it doesn't need escaping. It shouldn't make a difference, though.

    The following should redirect all requests for https://www.example.com/.\* to http://www.example.com/:


    but the path will be lost as Privoxy doesn't see it.

    Also note that Firefox no longer supports proxy redirects for CONNECT request and will simply show a misleading error message about not being able to connect to the server. I think Mozilla broke this in version 3 or 4 and I suspect that it was intentional.

    Using stunnel to MITM the connection before sending the redirect should work, but I'm not familiar with it's competition, so I don't know if there are better options available nowadays.

    Using stunnel is a bit inconvenient as you have to generate the fake certificates yourself. Before using it I'd recommend that you look for a similar tool that generates the certificates automatically first.


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks