I always thought HSTS headers were server specific, what reason would cause this header to not be invoked across certain URI endpoints i.e. HSTS header is in response to the root direct /, as well as /contact/doctors, but not in /contact/nurses.
Could someone please explain this to me?
All HTTP(S) headers are just data that the server sends over the wire. It's literally just plain text, usually ASCII/UTF-8. The server can send whatever headers (or body) it is configured for in response to whatever request it receives. Although it is common to configure a server to send certain headers with every response, doing so is neither the only option nor necessarily the best.
Sometimes different responses are sent for efficiency reasons, such as not sending headers to browsers so old they won't understand, or serving different HTTP/CSS/JS to different browsers (remember, the headers - like the body - are just data and can be controlled arbitrarily). Sometimes different paths have difference content or security policies. However, servers can be configured to do anything that any other software could do; for a particularly silly example, the server could skip sending any proper HTTP response at all for every 100th request, and just reply with the text of "I'm a little teapot". This would be a bad user experience, but it wouldn't be that hard to configure a server to do it (most web frameworks will automatically send at least the top line, with the response code, but you can avoid that with some effort).
Also, be aware that there's no 1:1 mapping of domain names to servers. A single domain name might be served by many different servers on the back end, with a piece of software sitting at the public address of the domain, terminating TLS, and routing the request to one of many back-end servers. Some of those back-end servers might send HSTS headers with every request, some with none, some on some other condition (probably not "alternating Thursdays", but it could be!).
The HSTS header should be returned for every URI for it to be considered effective. This is because while the header is host wide (optionally including sub-domains), there's nothing to stop a user accessing a resource first which does not return a HSTS header (in your example /contact/nurses), and therefore being allowed to communicate with that URI insecurely.
As soon as a client which implements the RFC correctly sees a HSTS header by accessing a URI which returns one (/contact/doctors in your example), the client will then enforce the header for the entire domain (and optionally sub-domains if the header requries that).
I have seen this mis-configuration used intentionally in the past, for example: where the inent (again using your example) is that /contact/nurses URI is accessed by a particular mobile app, or subset of clients, which for some reason the admin/developer want to do so over HTTP rather than HTTPS. In the case of a developer controlled client such as a mobile app, this can technically work as the developer can ensure the client never accesses a resource that returns a HSTS header.
