HTTP equivalent did not finish at HTTPS in ShipReady's bounded probe
ShipReady's successful request to the HTTP equivalent of a fetched HTTPS page did not finish on an HTTPS URL after redirects.
Why it matters
A production deployment can deliberately redirect plain HTTP requests to HTTPS. This finding identifies an observed HTTP-to-HTTPS redirect condition for review; it does not establish browser behavior across every route or network condition.
How ShipReady detects it
What it inspects
ShipReady runs this origin-scoped probe only after a readable, content-serving page has a final HTTPS URL. It makes one request to that page's HTTP equivalent and follows redirects.
What triggers a finding
The rule triggers when the HTTP probe receives an answer and its final URL after redirects does not use HTTPS.
What the evidence shows
The reported HTTP equivalent answered ShipReady's bounded probe without ending at an HTTPS URL.
Limits of this check
Connection failures, timeouts, rate-limit or origin-error responses are treated as inconclusive and do not create this finding. ShipReady does not test every route, browser upgrade state, HSTS cache, network interception, or all redirect behavior visitors may encounter.
How to fix it
Configure the intended HTTP-to-HTTPS redirect
Review the proxy, CDN, load balancer, and application settings that answer HTTP requests. Configure the intended HTTP URL space to redirect to the corresponding HTTPS destination.
Review representative routes
Test the intended redirect behavior for representative hostnames and paths in production. This finding is based on one HTTP-equivalent probe, not a complete route inventory.
How to verify the change
Inspect the HTTP redirect chain
Request the affected HTTP URL and inspect the final URL after redirects from a controlled environment.
Expected: The intended HTTP URL completes at the corresponding HTTPS destination.