HTTPS page contains static HTTP subresource references
ShipReady found one or more static HTTP subresource references in a successfully fetched HTTPS page.
Why it matters
HTTP subresource references on an HTTPS page are deployment signals to review. They can affect how a browser handles a resource, but a static reference alone does not show that the resource was requested, loaded, upgraded, or blocked.
How ShipReady detects it
What it inspects
On a successfully fetched final HTTPS page with status 200, ShipReady scans static HTML for HTTP URLs in script src, iframe src, image src, and stylesheet link href attributes.
What triggers a finding
The rule triggers when one or more of those supported attributes contains a non-ignored HTTP host. Duplicate URLs are collapsed; localhost, loopback, and W3.org namespace hosts are excluded.
What the evidence shows
The fetched HTTPS page contained at least one supported static HTTP subresource reference outside ShipReady's ignored-host list.
Limits of this check
ShipReady does not fetch the referenced subresources, execute browser code, inspect every attribute or route, or observe browser mixed-content blocking, upgrading, loading, or transport behavior. Links used for navigation are outside this rule.
How to fix it
Review each reported resource reference
Confirm whether the reported resource is intended and whether a suitable HTTPS URL is available from that provider or deployment.
Update references and test the page
Use an intentional HTTPS resource URL where appropriate, then test the affected page in supported browsers and review the resource's actual response behavior.
How to verify the change
Verify the rendered deployment
Inspect the deployed markup and use browser developer tools to verify the resources the application actually requests.
Expected: The intended page no longer contains unsupported HTTP subresource references, and its tested resource loading behavior is intentional.