However, this header is (or was) used by several HTTP servers/proxies (including Apache, I believe) to notify the application that the client connection is established in HTTPS. Wordpress reacts to this header by generating https:// URLs, which may not work if the server doesn't serve HTTPS with a properly configured certificate.
Otherwise app code that's _checking_ the flag, to ensure that a sensitive URL is only being accessed via HTTPS can be spoofed by the client simply saying it's HTTPS when it's not. That doesn't seem right.
If that's what's going on, it seems like a bug in apache, with security consequences.
?
The problem is, the using "HTTPS" HTTP header (that translates to "HTTP_HTTPS" environment variable in CGI terms) is a kludge. It should've been bare "HTTPS" variable in a same manner "REQUEST_ADDR" is, but someone didn't care much (or wasn't able to do things properly in early days) but shared a recipe that became so widespread, it's a nearly de-facto standard now. Or maybe this had evolved when TLS termination proxies were much more common, but due to laziness the recipe had eventually lost mandatory sanitization of X-Forwarded-For and HTTPS headers.
Still, if webserver is unaware of HTTPS (say, it had never ever had anything with TLS) it's not really webserver's fault it's not dropping some request header.
I believe it is known that some old reverse-proxies used this header before a standard solution emerged (X-forwarded-proto), Wordpress probably had to deal with this surprising behavior at some point.
Also, by naming a header "HTTPS", one could expect collision with a non-standard behavior: this is very common with HTTP/1.1.
In practice, with X-Forwarded-Proto, they don't, unless they can authenticate the downstream hop.
Let's say you configure your frontend server to set X-Foo and X-Bar fields. First, it should always send a header to the application indicating that it's messing with X-Foo and X-Bar, say "X-Added-By-My-Webserver: X-Foo, X-Bar". That way, the application can be sure that the frontend server is properly configured. Next, it should strip any X-Foo, X-Bar, and X-Added-By-My-Webserver, to prevent the client from being able to confuse the application with information the application expects to receive from the server.
This is still flaky because the frontend server could fail, and the user could send X-Added-By-My-Webserver, and so on, but if you must use in-band signalling, this seems like the safe route. Just blissfully adding a header is not enough to protect against evil or changing user agents.
Furthermore, it seems like a bad idea to make up your own header and not use an X- prefix.
In fact, we aren't talking about application headers. The HTTP RFC makes a distinction between application headers and hop-by-hop headers. There are mechanisms that proxies are required to implement, but they still don't.
For instance, a proxy must declare itself by appending its signature to a "Via" header - however most of them don't.
The RFC about forwarded HTTP extension is unclear about how a hop should deal with those headers, there is no one-size-fit-all situations: http://tools.ietf.org/html/rfc7239#section-8.1
Surely only the most obscure, ancient legacy systems would have problems with being redirected to https?
A client may have reasons to prefer HTTP over HTTPS: perfs, plaintext for debug, etc. It's hard to assume that "HTTPS should be the default" in any circumstance.
I'm not sure the wordpress sites are to blame here (for once): SSL isn't free to deploy (yet).
If you have a site that gets enough traffic that you need a better supported or more validated certificate, then I'm sure the $40/yr for a cheapass godaddy cert is worth the money.
No, even a free certificate doesn't mean that deploying ssl is free.