Re: [whatwg/fetch] Deferred fetching (PR #1647)

@mingyc commented on this pull request.

Thank you noamr@! I've added some last comments. And also added the missing features from the original proposal belows. Please let us know if they are suitable here.

1. Should this spec mention [Permission Policy]https://www.w3.org/TR/permissions-policy/? In https://github.com/WICG/pending-beacon/issues/77, the suggestion is to allow the API by default. But we might want to provide a way to manage 3rd party iframe's usage.
2. https://github.com/WICG/pending-beacon/issues/40 Should this spec mention retry when `fetchLater()` fails to send/commit?
3. The original PendingBeacon proposal also includes https://github.com/WICG/pending-beacon/issues/34, not sure how it can be incorporated into fetch spec.

> +<pre class=idl>
+
+dictionary DeferredRequestInit : RequestInit {
+  DOMHighResTimeStamp backgroundTimeout;
+};
+
+interface FetchLaterResult {
+  readonly attribute boolean sent;
+};
+
+partial interface mixin WindowOrWorkerGlobalScope {
+  [NewObject] FetchLaterResult fetchLater(RequestInfo input, optional DeferredRequestInit init = {});
+};
+</pre>
+
+<p>A {{FetchLaterResult}} has an associated <a>deferred fetch record</a>

> interface FetchLaterResult {
>     readonly attribute boolean sent;
> };
> <p>A `FetchLaterResult` has an associated <a>deferred fetch record</a> <dfn for=FetchLaterResult>deferred record</dfn>.

Sorry about this naive question:

The above speficies that a `FetchLaterResult` has only a single field, `sent`. However, a `deferred fetch record` has not only `sent` but also other fields like `request`, `invoke state`, and `inactivity deferred delay`:

- Are the two `sent` fields the same one, i.e. stored in same memory space? If not, should they be updated simultaneously (or in atomic way) everytime the record gets updated?
- It looks like [the fetchLater algorithm](https://whatpr.org/fetch/1647/094ea69...152d725.html#deferred-fetch-record) does not specify when `FetchLaterResult.sent` gets updated after `fetchLater()` returns? ([deferred fetch record](https://whatpr.org/fetch/1647/094ea69...152d725.html#deferred-fetch-record) does specify when to update its `sent` to true at the end though)

> @@ -8481,6 +8615,75 @@ with a <var>promise</var>, <var>request</var>, <var>responseObject</var>, and an
 </div>
 
 
+<h3 id=fetch-later-method>FetchLater method</h3>
+
+<pre class=idl>
+
+dictionary DeferredRequestInit : RequestInit {
+  DOMHighResTimeStamp backgroundTimeout;
+};
+
+interface FetchLaterResult {
+  readonly attribute boolean sent;
+};
+
+partial interface mixin WindowOrWorkerGlobalScope {
+  [NewObject] FetchLaterResult fetchLater(RequestInfo input, optional DeferredRequestInit init = {});

`fetchLater(RequestInfo input, ...)`

We have previously discussed this in https://github.com/WICG/pending-beacon/issues/72#issuecomment-1488081374:

`RequestInfo` allows setting some fields that may not make sense in the context of deferred fetching. For example.

- `keepalive` should always be true. Otherwise, it means the browser should drop the request immediately when document is destroyed.
- `method`: should be `GET` or `POST`. For CORS mode, browser may inistiate `HEAD` but I am not sure if it make senses to allow users manually doing so. For other HTTP methods, it's not in the goal of the original pending beacon proposal.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/1647#pullrequestreview-1512215771
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/pull/1647/review/1512215771@github.com>