- From: Ming-Ying Chung <notifications@github.com>
- Date: Wed, 23 Aug 2023 22:43:10 -0700
- To: whatwg/fetch <fetch@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/fetch/pull/1647/review/1592785018@github.com>
@mingyc commented on this pull request. PTAL > + throw a {{NotAllowedError}}. + + <p class=note>User-agents can, for example, decide that deferred fetching is not allowed for + subframes or gated behind some permission. + </li> + + <li><p>Let <var>requestObject</var> be the result of invoking the initial value of {{Request}} as + constructor with <var>input</var> and <var>init</var> as arguments. This may throw an exception. + + <li><p>If <var>requestObject</var>'s <a for=Request>signal</a> is <a for=AbortSignal>aborted</a>, + then throw <a for=Request>signal</a>'s <a for=AbortSignal>abort reason</a>. + + <li><p>Let <var>request</var> be <var>requestObject</var>'s <a for=Request>request</a>. + + <li><p>If <var>request</var>'s <a for=request>URL</a>'s <a for=url>scheme</a> is not an + <a>HTTP(S) scheme</a> then throw a {{TypeError}}. ``` If request’s URL’s scheme is not an HTTP(S) scheme then throw a TypeError. ``` Should this be HTTPS-only? (although there's a potentially trustworthy check below) According to our previous [discussion] and https://github.com/WICG/pending-beacon/issues/27, our new API should enforce security requests. > + <p><a for=list>For each</a> <a for="fetch group">deferred fetch record</a> + <var>deferredRecord</var> of <var>fetchGroup</var>'s + <a for="fetch group">deferred fetch records</a>: + + <ol> + <li><p>Set <var>deferredRecord</var>'s <a for="deferred fetch record">invoke state</a> to + "<code>terminated</code>". + + <li><p><a for=/>Fetch</a> <var>deferredRecord</var>'s + <a for="deferred fetch record">request</a>. + </ol> + </li> +</ol> + +<p>When a <a for=fetch>fetch group</a> <var>fetchGroup</var> is +<dfn export for="fetch group" id=concept-fetch-group-deactivate>deactivated</dfn>: ``` When a fetch group fetchGroup is deactivated: ... 1. Set deferredRecord’s [ invoke state ] to " scheduled ". ... The user agent should wait until deferredRecord’s [ inactivity delay ] have passed or until deferredRecord’s [ invoke state ] is not "scheduled" ``` It does not talk about the case when the fetch group transition from `deactivated` -> `activated` again while the inactivity delay has not passed. For example, `deactivated -> 10 second -> activated` while inactivity delay=10 minutes. In such case, should the invoke state be set back to `deferred` such that the inactivity delay timer can know it should stop? > + + <li><p>Let <var>request</var> be <var>requestObject</var>'s <a for=Request>request</a>. + + <li><p>If <var>request</var>'s <a for=request>URL</a>'s <a for=url>scheme</a> is not an + <a>HTTP(S) scheme</a> then throw a {{TypeError}}. + + <li><p>If <var>request</var>'s <a for=request>URL</a> is not a + [=potentially trustworthy url=], then throw a {{SecurityError}}. + + <li><p>Let <var>backgroundTimeout</var> be null. + + <li><p>If <var>init</var> is given and <var>init</var>["<code>backgroundTimeout</code>"] + <a for=map>exists</a> then set <var>backgroundTimeout</var> to + <var>init</var>["<code>backgroundTimeout</code>"]. + + <li><p>If <var>backgroundTimeout</var> is not a {{DOMHighResTimeStamp}} then throw a {{TypeError}}. Thanks! In addition, there was a long privacy-related [discussion](https://github.com/WICG/pending-beacon/issues/3) around the max we should allow for backgroundTimeout. The conclusion was that browser can internally enforce a time limit (but the value is not specified). In Chrome's case we set it to 30 minutes (> BFCache's 10 minutes TTL), while FF's BFCache along is 40 minutes. I guess it's somehow implemented by the step `The user agent may wait for a longer or shorter period time, e.g., to optimize batching of deferred fetches. ` in [fetch groups](https://whatpr.org/fetch/1647/53e4c3d...71fd383.html#fetch-groups), but should we also explicitly mention this behavior here? -- Reply to this email directly or view it on GitHub: https://github.com/whatwg/fetch/pull/1647#pullrequestreview-1592785018 You are receiving this because you are subscribed to this thread. Message ID: <whatwg/fetch/pull/1647/review/1592785018@github.com>
Received on Thursday, 24 August 2023 05:43:17 UTC