You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Similarly, if neither a website backend or API backend is setup to route the root URL, then we redirect the 404 not found page from HTTP to HTTPS.
However, in cases where the agency has an API backend setup to route the root URL path (/), then any HTTP requests by default return a 400 HTTP error (see HTTPS by default #34, but basically for API requests we've avoided returning redirects, since API clients may not follow those).
In this last case where the root URL is being treated as an API request, we've had a couple agencies request that the root / URL perform a 301 redirect from HTTP to HTTPS (instead of the 400 HTTP response) to simplify compliance and scanning results (since automated scanning tools that check the root URL may not consider the 400 HTTP response as enforcing HTTPS). In all of these cases, there's not actually an API that lives directly at the root / path, so performing a redirect for only the root path should be relatively safe. Sub-paths besides the root URL will still return a 400 error for HTTP requests (since we do still want to avoid redirects on other API endpoints for legacy purposes), so this change would only affect the root URL behavior.
The text was updated successfully, but these errors were encountered:
/
), then any HTTP requests by default return a 400 HTTP error (see HTTPS by default #34, but basically for API requests we've avoided returning redirects, since API clients may not follow those).In this last case where the root URL is being treated as an API request, we've had a couple agencies request that the root
/
URL perform a 301 redirect from HTTP to HTTPS (instead of the 400 HTTP response) to simplify compliance and scanning results (since automated scanning tools that check the root URL may not consider the 400 HTTP response as enforcing HTTPS). In all of these cases, there's not actually an API that lives directly at the root/
path, so performing a redirect for only the root path should be relatively safe. Sub-paths besides the root URL will still return a 400 error for HTTP requests (since we do still want to avoid redirects on other API endpoints for legacy purposes), so this change would only affect the root URL behavior.The text was updated successfully, but these errors were encountered: