I'm using a setup where HTTPS is served by a Pound HTTPS accelerator in front of Varnish and a pool of Nginx nodes behind that.

(HTTP hits Varnish directly and the request is forwarded to an Nginx back-end if necessary, while HTTPS hits Pound directly and is forwarded to Varnish as normal HTTP traffic with an appropriate X-Forwarded-Proto header... which in turn tells Nginx to set the appropriate HTTPS flag internally, making Drupal behave as expected.)

Anyway; I experienced a terrible HTTPS loop when going from a HTTPS page to one that was configured in Secure Pages to be non-HTTPS. After a lot of digging it turns out that Secure Pages sets the appropriate "Location" header to a HTTP version of the page... but Pound actually rewrote the Location string to the HTTPS version. Hence it ended up being a never-ending redirect from HTTPS to HTTPS.

The solution is to set RewriteLocation to 0 in the ListenHTTPS section of the pound configuration.

Here's the MAN section on the option:

RewriteLocation 0|1|2
If 1 force Pound to change the Location: and Content-location: headers in responses. If they point to the back-end itself or to the listener (but with the wrong protocol) the response will be changed to show the virtual host in the request. Default: 1 (active). If the value is set to 2 only the back-end address is compared; this is useful for redirecting a request to an HTTPS listener on the same server as the HTTP listener.

I think it would be worth putting a note about this on the project front page and/or README, as Pound is pretty commonly used.

Comments

meecect’s picture

meecect commented

This sounds very close to an error we are having right now. We will try your fix to see if it helps. BTW, what tools were you using to debug this and find this information out?

sigveio’s picture

sigveio commented

Uhm... from what I recall, quite a bit of good old digging. Systematically walking through everything involved, from the code down to the various infrastructure components to see what was happening and what was responsible for it. From adding debug output I saw that my Location header was being set appropriately, but ended up as https somewhere between that and the headers I observed using browser dev tools. I believe I then examined the Varnish traffic (using varnishlog and such), and saw that the redirect had already happened there. In front of Varnish is Pound, so that was the next to look into. Reading the documentation I found the option mentioned above, which seemed likely to be the culprit. I then tested and confirmed my theory. :-)

astonvictor’s picture

astonvictor commented
Status: Active » Closed (outdated)

I'm closing it because the issue was created a long time ago without any further steps.

if you still need it then raise a new one.
thanks