This section is non-normative.
This specification defines a method for discovering if an HTTP server is misconfigured in this way.
This specification depends on the Infra Standard. [INFRA]
2. Detecting the reliability of HTTP status codes
We can see if a web server’s statuses are reliable by fetching a URL that should never result in an ok status. If the response status (after following redirects) is an ok status, it’s safe to conclude that the server is not configured properly.
To test the reliability of an origin’s response status codes given origin, run the following steps:
Let p be a new promise.
If origin is not a tuple origin, reject p and return it.
Let status reliability queue be the result of starting a new parallel queue.
Enqueue the following steps to status reliability queue:
Let url be the result of calling
URL(url, base)with url "/.well-known/resource-that-should-not-exist-whose-status-code-should-not-be-200" and base origin.
Let request be a new request whose url is url, method is
GET, synchronous flag is set, origin is origin, mode is
"same-origin", service-workers mode is
"none", credentials mode is
"omit", cache mode is
"no-store", and redirect mode is
Let response be the result of performing a fetch using request.
If response is a network error, reject p.
If response’s status is an ok status, reject p. Otherwise, resolve p.
3. IANA considerations
resource-that-should-not-exist-whose-status-code-should-not-be-200 well-known URI
This document defines the “
This registration will be submitted to the IESG for review, approval, and registration with IANA using the template defined in [WELL-KNOWN] as follows:
- URI suffix
- Change controller
- Specification document(s)
This document is the relevant specification. (See § 2 Detecting the reliability of HTTP status codes)
- Related information:
Many thanks to Elaine Knight for their valuable feedback on this proposal.