X-HTTPS Header Not Sent For Subdomains

[Within The Pale]

Operating system:
Browser version:
32-bit or 64-bit browser?:
Problem URL:
Browser theme (if not default):
Installed add-ons:
Installed plugins: (about:plugins):

I apologize if this is not the correct forum for this, but I could not find anywhere else that seemed appropriate.

This is an observation, not necessarily a bug or other issue, that has left me quite puzzled. I have been observing over the last few days that Pale Moon sends an "X-HTTPS: 1" header for base domains like "abc.com", but not for subdomains like "xyz.abc.com". This is not an order of request issue. I can request "xyz.abc.com" from a clean start and I do NOT see the "X-HTTPS: 1" header sent; but if I subsequently request "abc.com", I DO see the "X-HTTPS: 1" header sent. This is a puzzlement to me. It may be by deliberate design, but I am curious as to the reasons why, if so. Thanks in advance for any info.

[Moonchild]

X-HTTPS is not a standard request header. It does seem some configurations of server front-ends add this header to pass to a back-end (e.g. using a reverse proxy) to explicitly indicate the initial connection to the server was made over https (as a back-end server might otherwise have no way to determine the inbound connection's TLS state if proxied) but that would be something that is done server-side.

[Within The Pale]

Thank you! I appreciate the rapid response.

So the X-HTTPS header is not something that Pale Moon is sending, but rather something that certain servers are injecting into the request headers before they arrive at the back-end processor, like PHP. Still weird how apparently inconsistent it is but at least that is a server issue, and can be ignored.

[Moonchild]

something that certain servers are injecting into the request headers before they arrive at the back-end processor, like PHP

Correct. So if PHP is sitting behind e.g. Apache, then Apache may be configured to pass on this header if the browser connection to Apache was made over https (since your PHP in that case might not be able to directly see the connection was https if the URL also does not retain that information or is not passed down). The inconsistency would be because of how Apache is configured in that case.