-
Notifications
You must be signed in to change notification settings - Fork 22
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
Clarify & simplify #19
Conversation
<li>The user agent MUST NOT skip or throttle processing of beacon | ||
requests, as it may contain critical application state, events, and | ||
analytics data.</li> | ||
<li>The user agent MUST process the response headers, and if provided, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does this mean?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awkward language. What we need to say is: user agent should run the request to completion, process returned set-cookies, etc, but ignore the response body if any is given.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should really follow from the usage of Fetch. Having all these duplicate requirements on top of those is very sketchy.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do think we can simplify it, assuming we can upstream some logic to Fetch..
- max payload size should be enforced by code handling the sendBeacon; the requirement should live in this spec.
- prioritization/coalescing + flush should live in Fetch.. if we agree that Request coalescing as a platform primitive? #20 is reasonable.
- Agree that response headers bits are probably redundant; is there a hook in fetch to avoid processing body, etc, if we set request type to beacon?
@annevk updated privacy & acknowledgement sections. ptal. |
Merging, we can continue to iterate in followup issues. |
Preview: https://rawgit.com/w3c/beacon/clarify-simplify/index.html
An attempt at reworking the introduction, processing rules, and privacy and security sections to more accurately describe the problem sendBeacon is intended to solve, and how it should go about doing so.
In theory, this should go a long way towards addressing issues raised in: #14, #18, #13, #17.
Is it heading in the right direction?