-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Fetch-Based API] Handling Request Size Limit #76
Labels
Comments
Today's discussion:
cc @noamr |
One thing to be wary of, and that per-origin quota helps a lot with, is weird dynamics that can be created if the quota is shared between multiple 3P vendors on the page. |
mingyc
added a commit
to mingyc/pending-beacon
that referenced
this issue
Jul 4, 2023
mingyc
added a commit
to mingyc/pending-beacon
that referenced
this issue
Jul 4, 2023
mingyc
added a commit
to mingyc/pending-beacon
that referenced
this issue
Jul 4, 2023
mingyc
added a commit
to mingyc/pending-beacon
that referenced
this issue
Jul 4, 2023
See https://whatpr.org/fetch/1647.html#deferred-fetching:
...
|
Subsequent request-related discussion in #87 to avoid confusion |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Context: #70 #71
As setting
deferSend
implieskeepalive
is also true, such request has to share the same size limit budget as a regular keepalive request’s one: "for each fetch group, the sum of contentLength and inflightKeepaliveBytes <= 64 KB".To comply with the limit, there are several options:
fetch()
throwsTypeError
whenever the budget has exceeded. Users will not be able to create new pending requests.fetch()
should still throwsTypeError
.The text was updated successfully, but these errors were encountered: