HSTS not checked at both https endpoints

[climber-girl]

While looking at egeo.usss.gov for HTTPS/HSTS issues per customer request for assistance to understand why 'Enforces HTTPS' was failing (based on the most recent code change we made here: #192, http-www endpoint was correctly causing this failure because it doesn't redirect to an https site), I noticed that the https-www endpoint also does not have an HSTS header. The report is incorrectly showing Strong HSTS = True because it is based on the HSTS header of the plain https endpoint.

I think a change similar to the "Bugfix for domain_enforces_https() logic" at link above needs to be done to ensure that both the plain https and the https-www endpoints are checked for Strong HSTS.

$ curl --head egeo.usss.gov
HTTP/1.1 301 Moved Permanently
Content-Length: 145
Content-Type: text/html; charset=UTF-8
Location: https://egeo.usss.gov/
Server: Microsoft-IIS/10.0
X-Powered-By: ASP.NET
Date: Fri, 07 Jun 2019 15:38:14 GMT

$ curl --head https://egeo.usss.gov
HTTP/2 200
content-length: 783
content-type: text/html
last-modified: Tue, 14 May 2019 19:52:48 GMT
accept-ranges: bytes
etag: "1d50a8e9b092b0f"
server: Kestrel
set-cookie: ApiUrl=https%3A%2F%2Fegeo.usss.gov%2FAtlasLogin%2F; path=/
x-powered-by: ASP.NET
strict-transport-security: max-age=31536000
date: Fri, 07 Jun 2019 15:38:26 GMT

$ curl --head www.egeo.usss.gov
HTTP/1.1 404 Not Found
Content-Length: 315
Content-Type: text/html; charset=us-ascii
Server: Microsoft-HTTPAPI/2.0
Date: Fri, 07 Jun 2019 15:38:53 GMT
Connection: close

$ curl --head https://www.egeo.usss.gov
HTTP/2 404
content-length: 315
content-type: text/html; charset=us-ascii
server: Microsoft-HTTPAPI/2.0
date: Fri, 07 Jun 2019 15:38:41 GMT

[echudow]

@climber-girl, I agree. If both endpoints are live then they should both have HSTS and we should check for that. However, the code currently does a lot to scope things to only check the canonical endpoint rather than both types (root and www). I wonder what @h-m-f-t thinks?