-
Notifications
You must be signed in to change notification settings - Fork 36
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
Group endpoints by origin #67
Conversation
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.
Overall, looks good! My only question, before we merge this, is to sanity check that we're OK with the change to TTL behavior — see comment in review.
index.src.html
Outdated
Each <a>client</a> has an | ||
<dfn for="client" export attribute>endpoint-groups</dfn> list, which is a list | ||
of <a>endpoint groups</a>, each of which MUST have a distinct | ||
{{endpoint group/name}}. |
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 happens when you have a name collision? We should define what the UA should do here: first wins, last wins, abort the header, etc.
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.
Done.
The parsing algorithm already mandated "keep first", but I added a sentence here reinforcing that.
<dfn for="endpoint group" export attribute>subdomains</dfn> flag, which is | ||
either "`include`" or "`exclude`". | ||
|
||
Each <a>endpoint group</a> has a |
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.
Previously you could have different TTLs for each endpoint, this changes this to a group-wide TTL. Are we OK with that? Would you ever want to have different endpoints with different TTLs?
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.
Yeah, I think it makes more sense for the TTL to be per-group. I've view the TTL as describing how long the entire configuration is valid, not how long we expect any individual endpoint to be up. The delivery mechanism will gracefully handle if a dodgy endpoint goes down, and new header values always overwrite old ones, even if a TTL hasn't expired, so there's no worry about stale data persisting for too long.
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.
Makes sense. LGTM to merge from this end.
This is a pretty big change. It changes the reporting cache so that there's a single "client" entry for each origin. That client contains a list of "endpoint groups", each of which contains a list of "endpoints". These are the same objects as before, just organized differently. More importantly, this also changes the format of the JSON array in the `Report-To` header: - Each element in the array now describes an endpoint group, not an individual endpoint. - The `max-age` and `include-subdomains` properties now belong to endpoint groups, and not to individual endpoints.
Based on discussion on last WebPerf WG call: looks good, merging. |
This is a pretty big change. It changes the reporting cache so that there's a single "client" entry for each origin. That client contains a list of "endpoint groups", each of which contains a list of "endpoints". These are the same objects as before, just organized differently.
More importantly, this also changes the format of the JSON array in the
Report-To
header:Each element in the array now describes an endpoint group, not an individual endpoint.
The
max-age
andinclude-subdomains
properties now belong to endpoint groups, and not to individual endpoints.Preview | Diff