- From: Ming-Ying Chung <notifications@github.com>
- Date: Mon, 17 Jul 2023 19:50:15 -0700
- To: whatwg/fetch <fetch@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/fetch/pull/1647/c1639214552@github.com>
> > > Deferred fetch body sizes are limited to 64KB per origin. Exceeding this would immediately reject with a QuotaExceeded. > > > > > > Another note about "origin" of a beacon request: there were some previous discussion about using 3P storage partitioning key (not origin, which is stricter) to decide whether pending beacon requests in a page are sendable or not in terms of privacy concern, see [WICG/pending-beacon#30 (comment)](https://github.com/WICG/pending-beacon/issues/30#issuecomment-1333869614) and comments there below. I am not sure how this should be spec. > > OK, perhaps the 64kb constraint can be per [network partition key](https://fetch.spec.whatwg.org/#network-partition-key) rather than origin. @noamr Following up on [the sendable beacon discussion](https://github.com/whatwg/fetch/pull/1647#issuecomment-1550057237): As mentioned in https://github.com/WICG/pending-beacon/issues/30#issuecomment-1333869614, there were discussions around whether a beacon (or deferred request) should be sent when network changes. I tried to summarize them in [this PR](https://github.com/WICG/pending-beacon/pull/55/commits/feb3cf968933cebc823c4c6855d89f07bcf4005a, but basically to process a beacon request when BackgroundSync is off, we need to see if another open document (tab/frame/etc) with the same storage partitioning key as the current document's one, to avoid unexpected sending the request after network changes. Do you think the above makes sense to be integrated into Fetch spec? -- Reply to this email directly or view it on GitHub: https://github.com/whatwg/fetch/pull/1647#issuecomment-1639214552 You are receiving this because you are subscribed to this thread. Message ID: <whatwg/fetch/pull/1647/c1639214552@github.com>
Received on Tuesday, 18 July 2023 02:50:22 UTC