WordPress Installation behind reverse-proxy ssl redirect loop

[costasd]

Hello,

In my job, we are evaluating wordpress for our main site, and we seem to have a little problem with our setup.

First of all, our setup:
We use a pretty common setup with reverse proxy(nginx) in front of our LAMP stack. Nginx serves static files(e.g. images) and proxy-passes all other requests to apache2. Nginx handles both http & https, speaking http to backend(apache2)

The problem:
In setups like that, some server variables, are not used. This is why you have to use mod-rpaf on apache to get the client ip.
One of those variables, is $_SERVER['HTTPS'].
So in a setup with reverse-proxy in front, you have to set a variable $_SERVER['HTTP_X_FORWARDED_PROTO'] with value 'https', to make backend realize that its 'real' url is an https one.

Wordpress checks only for the $_SERVER['HTTPS'] variable, and gets caught in an endless loop redirection from https to http to https and so on. The way we got over that, is to check for the $_SERVER['HTTP_X_FORWARDED_PROTO'] header in wp-include/functions.php:is_ssl() function.

I'm submitting also our 3-line patch, in case anyone has the same problem. Patch tested and works with nginx reverse-proxy.

I'm tagging it as a defect/bug, if you think it is not a bug, please re-tag it.

Thanks in advance,
Costas

[nacin]

You should set $_SERVER['HTTPS'] to equal $_SERVER['HTTP_X_FORWARDED_PROTO'] in your wp-config.php file. This isn't an issue for core to solve.

[costasd]

Ah nice, thanks a lot :)

I am closing it

[nacin]

Cheers :)

[brettporter]

I have added some documentation on this to ​http://codex.wordpress.org/Administration_Over_SSL

I hope you'll reconsider including this in the core function since I noticed several people having this problem while I was searching, and it was quite difficult to track down a solution. Adding the extra check would be more likely to behave correctly out of the box.

[nacin]

This has also been discussed elsewhere. See ​http://core.trac.wordpress.org/ticket/19337#comment:4. Thanks for adding a note to the Codex.

[ziodave]

#24394 was marked as a duplicate.

[willnorris]

#15277 was marked as a duplicate.

[dd32]

#25222 was marked as a duplicate.

[SergeyBiryukov]

#30828 was marked as a duplicate.

[ocean90]

#31288 was marked as a duplicate.

[desrosj]

#38273 was marked as a duplicate.

[xani666]

X-Forwarded-For/Proto is de-facto standard ​https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-Proto

If you google for that problem there is countless posts of people having to fix it on their own.

Just fucking fix it instead of making shitty excuses of "just change configuration of everything else to accommodate our shitty whims"

[jorbin]

As the document you point specifically says:Not part of any current specification. While common, it is not a standard. Nothing has changed to make me think that the decision from 8 years ago should be changed.

If you would like to make a respectful justification for changing this decision, ideally with some stats, discussion can always continue on a closed ticket.

[xani666]

@jorbin You got 8 years of proof lack of handling of x-forwarded for is causing problem, right in this ticket, just look at amount of duplicates merged. Or just google it. Or just look at the docs of the one of most used LB services:

​https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/x-forwarded-headers.html

or LB daemons

​https://cbonte.github.io/haproxy-dconv/1.7/configuration.html#option%20forwardfor

And what exact RFC "set HTTPS header to on" is in, because I can't find any yet it is still what WP relies on. So please, stop with the "hurr durr it is not in official OFFICIAL official standard" because that's not how internet is built.

[lordspace]

I agree with @xani666 that WP should be smart about the environment it is running under.

[SergeyBiryukov]

#40013 was marked as a duplicate.

[costdev]

#42307 was marked as a duplicate.