diff --git a/fetch.bs b/fetch.bs index 016dc95cc..2c23aa451 100644 --- a/fetch.bs +++ b/fetch.bs @@ -2118,6 +2118,50 @@ clearly stipulates that connections are keyed on WebSocket saner --> +
To +determine the HTTP cache partition, +given request, run these steps: + +
Let topLevelOrigin be null. + +
If request's reserved client is non-null, then: + +
Set topLevelOrigin to request's reserved client's + top-level origin. + +
If topLevelOrigin is null, then set topLevelOrigin to + request's reserved client's + top-level creation URL's origin. + +
This happens for top-level navigations only. +
Otherwise, if request's client is non-null, set + topLevelOrigin to request's client's + top-level origin. + +
Otherwise, return null. + +
Assert: topLevelOrigin is an origin. + +
Let topLevelSite be the result of obtaining a site, + given topLevelOrigin. + +
Return the HTTP cache associated with topLevelSite and, possibly, a second key. + [[!HTTP-CACHING]] + +
The second key is intentionally a little vague as the finer points are still + evolving. See issue #1035. +
To determine whether fetching a request request @@ -4130,6 +4174,8 @@ Range Requests. [[HTTP-RANGE]] However, this is not widely supported by b
Let storedResponse be null. +
Let httpCache be null. +
Let the revalidatingFlag be unset.
Set httpCache to the result of determining the HTTP cache partition, + given httpRequest. + +
If httpCache is null, then set httpRequest's
+ cache mode to "no-store
".
+
If httpRequest's cache mode is neither "no-store
"
nor "reload
", then:
Set storedResponse to the result of selecting a response from the HTTP cache, - possibly needing validation, as per the +
Set storedResponse to the result of selecting a response from the + httpCache, possibly needing validation, as per the "Constructing Responses from Caches" chapter of HTTP Caching [[!HTTP-CACHING]], if any. @@ -4410,10 +4462,10 @@ Range Requests. [[HTTP-RANGE]] However, this is not widely supported by b
In parallel, perform main fetch using revalidateRequest. -
This fetch is only meant to update the state of the HTTP cache and the - response will be unused until another cache access. The stale response will be used as the - response to current request. This fetch is issued in the context of a client so if it goes - away the request will be terminated. +
This fetch is only meant to update the state of httpCache + and the response will be unused until another cache access. The stale response will be used + as the response to current request. This fetch is issued in the context of a client so if + it goes away the request will be terminated.
If httpRequest's method is
unsafe and
forwardResponse's status is in the range 200
to
- 399
, inclusive, invalidate appropriate stored responses in the HTTP cache, as per
- the "Invalidation" chapter of
+ 399
, inclusive, invalidate appropriate stored responses in httpCache, as
+ per the "Invalidation" chapter of
HTTP Caching, and set storedResponse to null. [[!HTTP-CACHING]]
Set response to forwardResponse.
Store httpRequest and forwardResponse in the HTTP cache, as per the - "Storing Responses in Caches" +
Store httpRequest and forwardResponse in httpCache, as per + the "Storing Responses in Caches" chapter of HTTP Caching. [[!HTTP-CACHING]]
If forwardResponse is a network error, this effectively caches @@ -4625,6 +4677,12 @@ Range Requests. [[HTTP-RANGE]] However, this is not widely supported by b
Let response be null. +
Let httpCache be the result of determining the HTTP cache partition, given + httpRequest. + +
If httpCache is null, then set request's cache mode
+ to "no-store
".
+
Switch on request's mode: @@ -4751,11 +4809,9 @@ Range Requests. [[HTTP-RANGE]] However, this is not widely supported by b total bytes to that payload body length. -
If response is not a
- network error and request's
- cache mode is not "no-store
",
- update response in the HTTP cache for request.
-
+
If response is not a network error and request's
+ cache mode is not "no-store
", then update response in
+ httpCache for request.
If credentials flag is set and the user agent is not configured to block cookies for @@ -7268,6 +7324,7 @@ Sendil Kumar N, Shao-xuan Kang, Sharath Udupa, Shivakumar Jagalur Matt, +Shivani Sharma, Sigbjørn Finne, Simon Pieters, Simon Sapin,