What's the de facto standard for a Reverse Proxy to tell the backend SSL is used?

I have a reverse proxy that does HTTPS on the outside, but HTTP on the inside.

This means that by default in-app URLs will have HTTP as the scheme, as this is the way it's being contacted.

How can the proxy tell the backend that HTTPS should be used?

The proxy can add extra (or overwrite) headers to requests it receives and passes through to the back-end. These can be used to communicate information to the back-end.

So far I've seen a couple used for forcing the use of https in URL scheme:

X-Forwarded-Protocol: https
X-Forwarded-Ssl: on
X-Url-Scheme: https

And wikipedia also mentions:

# a de facto standard:
X-Forwarded-Proto: https
# Non-standard header used by Microsoft applications and load-balancers:
Front-End-Https: on

This what you should add to the VirtualHost on apache: other proxies should have similar functionality

RequestHeader set X-FORWARDED-PROTOCOL https
RequestHeader set X-Forwarded-Ssl on
# etc.

I think it's best to set them all, or set one that works and remove the other known ones. To prevent evil clients messing with them.

It took me several hours of googling to find the magic setting for my environment. I have a SSL httpd Apache reverse proxy in front of a jetty app server and an apache2 http server. This answer actually gave me the information that worked. For me, adding:

RequestHeader set "X-Forwarded-Proto" expr=%{REQUEST_SCHEME}

to the site conf file was enough for the destination to use https instead of http as the protocol when building links in the response. I tried the X-FORWARDED-PROTOCOL above, but that didn't work. Hopefully this will help in future Google searches!