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

@fergald commented on this pull request.



> +   <a for=request>body</a>'s <a for=body>length</a>.
+  </ol>
+ </li>
+
+ <li><p><a for=list>For each</a> <a>deferred fetch record</a> <var>deferredRecord</var> in
+ <var>request</var>'s <a for=request>client</a>'s <a for=fetch>fetch group</a>'s
+ <a for="fetch group">deferred fetch records</a>: if <var>deferredRecord</var>'s
+ <a for="deferred fetch record">request</a>'s <a for=request>body</a> is not null and
+ <var>deferredRecord</var>'s <a for="deferred fetch record">request</a>'s <a for=request>URL</a>'s
+ <a for=url>origin</a> is <a>same origin</a> with <var>request</var>'s <a for=request>URL</a>'s
+ <a for=url>origin</a>, then increment <var>totalScheduledDeferredBytesForOrigin</var> by
+ <var>deferredRecord</var>'s <a for="deferred fetch record">request</a>'s <a for=request>body</a>'s
+ <a for=body>length</a>.
+
+ <li><p>If <var>totalScheduledDeferredBytesForOrigin</var> is greater than 64 kilobytes, then
+ throw a {{QuotaExceededError}}.

I know we had discussions about this but I don't remember coming to this conclusion (or really any strong conclusion). I think it's very difficult to manage this in userland. Beacons can be created in the 1st party origin by any 3rd party script. Even keeping it all 1st party, it would require *all* beacon usage in all 1st-party frames to go through a central point in order to correctly account for the bytes. That seems like a heavy burden on devs.

I realise that speccing this behaviour might be hard and maybe could come later. Implementers have some leeway on when to send, so maybe we could implement the autoflushing behaviour even if it's not explicitly in the spec.

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

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