Skip to content
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

Merged
merged 2 commits into from
Dec 9, 2015
Merged

Clarify & simplify #19

merged 2 commits into from
Dec 9, 2015

Conversation

igrigorik
Copy link
Member

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?

@igrigorik
Copy link
Member Author

<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,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does this mean?

Copy link
Member Author

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.

Copy link
Member

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.

Copy link
Member Author

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?

@igrigorik
Copy link
Member Author

@annevk updated privacy & acknowledgement sections. ptal.

igrigorik added a commit that referenced this pull request Dec 9, 2015
@igrigorik igrigorik merged commit 44e4913 into gh-pages Dec 9, 2015
@igrigorik
Copy link
Member Author

Merging, we can continue to iterate in followup issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants