Description:
------------
---
From manual page: http://www.php.net/reserved.variables.server
---

It is pretty common for apps accessed by HTTPS to sit behind a load balancer that terminates the SSL connection and issue an plain HTTP request setting the X-FORWARDED-PROTO headers.

See http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/TerminologyandKeyConcepts.html#x-forwarded-headers and http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/TerminologyandKeyConcepts.html#x-forwarded-headers 

The documentation at http://www.php.net/reserved.variables.server states:"'HTTPS'
    Set to a non-empty value if the script was queried through the HTTPS protocol. "

but does not precise whether this variable is expected to be set when the X-FORWARDED-PROTO=HTTPS header was present, or more generally if the request was received through SSL-termination load balancer effectively making it secure.

As a result of this lack of precision in the documentation:
- some php web frameworks (e.g. http://symfony.com/doc/current/components/http_foundation/trusting_proxies.html ) implement the logic themselves by testing the $SERVER['X-FORWARDED-PROTO'] variable.
- some php apps that rely on $SERVER['HTTPS'] without testing against $SERVER['X-FORWARDED-PROTO'] might incorrectly assume they are queries in HTTP format, e.g. https://github.com/commandprompt/phpldapadmin/issues/1
- some php infrastructure providers (e.g. Cloud platform-as-a-service) are not clear on whether to automatically set $SERVER['HTTPS'] upon presence of X-FORWARDED-PROTO HTTP header when it is trusted to represent the originally received protocol for the request.

Suggested fix to documentation:


"'HTTPS'
    Set to a non-empty value if the script was queried through the HTTPS protocol, directly or through a trusted upstream SSL-termination load balancer. "