diff --git a/fetch.bs b/fetch.bs index b023ee89c..b3f54c635 100644 --- a/fetch.bs +++ b/fetch.bs @@ -2940,35 +2940,33 @@ run these steps:
Cross-Origin-Resource-Policy
` headerThe +
Servers can use the
`Cross-Origin-Resource-Policy
`
-response header can be used to require checking a request's
-current URL's origin against a request's
-origin when request's mode is
-"no-cors
".
+response header to control the contexts into which a given resource may be loaded. The
+restrictions asserted by this header apply to "no-cors
" subresource requests and to
+navigation requests that target a frame or a window that's accessible from the request's
+initiator.
-Cross-Origin-Resource-Policy = %s"same-origin" / %s"same-site" ; case-sensitive
+Cross-Origin-Resource-Policy = %s"same-origin" / %s"same-site" / %s"cross-site" ; case-sensitive
To perform a cross-origin resource policy check, given a request and response, run these steps:
If request's mode is not "no-cors
", then return
- allowed.
-
If request's origin is same origin with - request's current URL's origin, then return - allowed. +
Return allowed if either of the following statements is true: +
request's mode is "same-origin
",
+ "cors
", or "websocket
".
-
While redirects that carry a
- `Cross-Origin-Resource-Policy
` header are checked, redirects
- without such a header resulting in response do not contribute to this algorithm. I.e.,
- request's tainted origin flag is not checked.
+
request is a navigation request whose reserved client + is an environment whose target browsing context is neither a + nested browsing context nor an auxiliary browsing context. +
Let policy be the result of getting @@ -2976,31 +2974,65 @@ Cross-Origin-Resource-Policy = %s"same-origin" / %s"same-site" ; case-sensit header list.
This means that `Cross-Origin-Resource-Policy: same-site, same-origin
`
- ends up as allowed below as it will never match anything. Two or more
- `Cross-Origin-Resource-Policy
` headers will have the same effect.
-
-
If policy is `same-origin
`, then return blocked.
+ ends up as allowed as it will not match any of the explicit options in the switch below.
+ Two or more `Cross-Origin-Resource-Policy
` headers delivered in
+ the same response will similarly fall through to allowed below.
If the following are true +
If policy is null, and request's client's
+ responsible browsing context's active document's
+ x-bikeshed-cross-origin-resource-policy-policy flag is set, then set policy to
+ "same-origin
".
-
https
" or response's HTTPS state is
- "none
"
- This is a straw-proposal to clarify a suggestion in + issue #4175. The flag isn't yet defined, + and might end up looking completely different. -
then return allowed. +
same-origin
"
+ If request's origin is same origin with + request's current URL's origin, return + allowed. +
This prevents HTTPS responses with
- `Cross-Origin-Resource-Policy: same-site
` from being accessed without secure
- transport.
+
same-site
"
+ Return allowed if the following are true: +
If policy is `same-site
`, then return blocked.
+
https
" or response's HTTPS state is
+ "none
"
+ `Cross-Origin-Resource-Policy: same-site
` does not consider a
+ response delivered via a secure transport to match a non-secure requesting origin, even if
+ their hosts are otherwise same site. Securely-transported responses will only match a
+ securely-transported initiator.
-
Return allowed. +
Otherwise, return blocked. +
cross-site
"
+ Return allowed. + +
While redirects that carry a
+ `Cross-Origin-Resource-Policy
` header are checked, redirects
+ without such a header resulting in response do not contribute to this algorithm. I.e.,
+ request's tainted origin flag is not checked.