Intent To Ship: Provide network quality estimates to web servers via Client Hints
Contact emails
tba...@chromium.org, igri...@chromium.org, be...@chromium.org,
Explainer
https://github.com/WICG/netinfo/issues/46#issuecomment-276804272
Spec
NetInfo spec: https://wicg.github.io/netinfo/
WICG thread: https://discourse.wicg.io/t/proposal-netinfo-provide-effective-network-speed-expose-save-data/1980
Summary:
This is a proposal to ship three new client hints (and corresponding three HTTP request headers) to convey the HTTP client's network connection speed. The headers will be sent individually, and will be sent only to hosts that opt in to receiving them using the existing client hints mechanism. The headers will surface the same data as the Network Information API to make it easy to make network speed-related decisions. The three new headers are “rtt”, “downlink” and “ect” and they provide the same value as existing NetInfo APIs (navigator.connection.rtt, navigator.connection.downlink and navigator.connection.effectiveType, respectively).
Link to “Intent to Implement” blink-dev discussion
Intent to implement: https://groups.google.com/a/chromium.org/d/topic/blink-dev/TS9zT_u2M4k/discussion
(Related) Intent to ship for NetInfo JavaScript API: https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/UVfNMH50aaQ/XQiWq35WCAAJ
(Related) Intent to ship for client hints: https://groups.google.com/a/chromium.org/d/topic/blink-dev/8RBFue7RMXQ/discussion
Motivation:
See explainer for detailed motivation.
Web servers and proxies benefit, because they can tailor content to network constraints. For example, on very slow networks, a simplified version of the page can be provided to improve document load and first paint times. Users benefit by being offered only that content that they can consume given network constraints, which results in faster paints, and less frustration.
Providing network quality as a client hint allows origins to adapt the HTML content of the webpage immediately without incurring an extra RTT from querying the JavaScript API.
Interoperability and Compatibility Risk:
Low. Opt-in header and extension to existing client hints mechanism and NetInfo API.
Activation
Activating this feature should be straightforward since the web servers simply need to add couple of more attributes (e.g., “rtt”, “downlink”, “ect” or their combination) to the existing Accept-CH header.
Ongoing technical constraints:
None.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
Demo link
https://bit.ly/client-hints-demo
Debuggability
The network quality estimates are also exposed via chrome://net-internals. Developers can use net-internals, in a local environment to better understand the behavior of the estimation process: open Events tab and look for “network_quality_estimator” records. Developers can also override the network quality estimate using the Chrome switch “force-effective-connection-type” which can be set from chrome://flags or as a command line switch.
Requesting Approval to Ship?
Yes.
OWP launch tracking bug:
https://bugs.chromium.org/p/chromium/issues/detail?id=826950
Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.
There are existing tests for NetInfo JavaScript API (https://wpt.fyi/netinfo) as well as client hints (https://wpt.fyi/client-hints). We need to add these rtt, downlink and ect client hints to the existing client hints test suite. Tracking bug: https://bugs.chromium.org/p/chromium/issues/detail?id=835333
Entry on the feature dashboard
https://www.chromestatus.com/feature/5407907378102272
The plan is to update the fetch spec and the Blink implementation to handle the new headers. Plan here (thanks Yoav!): https://github.com/whatwg/fetch/issues/707#issuecomment-383874881As far as the same origin policy is concerned, these headers should be treated similar to other currently existing client hints headers (dpr, width etc.). We plan to update the fetch spec to add the new headers: https://fetch.spec.whatwg.org/#terminology-headers, and then update the Blink implementation to conform with the spec.
On Tue, Apr 24, 2018 at 7:07 PM Tarun Bansal <tba...@chromium.org> wrote:The plan is to update the fetch spec and the Blink implementation to handle the new headers. Plan here (thanks Yoav!): https://github.com/whatwg/fetch/issues/707#issuecomment-383874881As far as the same origin policy is concerned, these headers should be treated similar to other currently existing client hints headers (dpr, width etc.). We plan to update the fetch spec to add the new headers: https://fetch.spec.whatwg.org/#terminology-headers, and then update the Blink implementation to conform with the spec.To be clear: you're planning to go ahead with the spec changes before shipping?
On Thu, Apr 26, 2018 at 8:34 AM Yoav Weiss <yo...@yoav.ws> wrote:On Tue, Apr 24, 2018 at 7:07 PM Tarun Bansal <tba...@chromium.org> wrote:The plan is to update the fetch spec and the Blink implementation to handle the new headers. Plan here (thanks Yoav!): https://github.com/whatwg/fetch/issues/707#issuecomment-383874881As far as the same origin policy is concerned, these headers should be treated similar to other currently existing client hints headers (dpr, width etc.). We plan to update the fetch spec to add the new headers: https://fetch.spec.whatwg.org/#terminology-headers, and then update the Blink implementation to conform with the spec.To be clear: you're planning to go ahead with the spec changes before shipping?Just had a chat with Tarun and he agreed to go ahead with the relevant Fetch spec changes, adding the new headers to the Client Hints list as well as the CORS-safelisted request header list.So LGTM1, pending on said spec changes.
On Thu, Apr 26, 2018 at 8:34 AM Yoav Weiss <yo...@yoav.ws> wrote:On Tue, Apr 24, 2018 at 7:07 PM Tarun Bansal <tba...@chromium.org> wrote:The plan is to update the fetch spec and the Blink implementation to handle the new headers. Plan here (thanks Yoav!): https://github.com/whatwg/fetch/issues/707#issuecomment-383874881As far as the same origin policy is concerned, these headers should be treated similar to other currently existing client hints headers (dpr, width etc.). We plan to update the fetch spec to add the new headers: https://fetch.spec.whatwg.org/#terminology-headers, and then update the Blink implementation to conform with the spec.To be clear: you're planning to go ahead with the spec changes before shipping?Just had a chat with Tarun and he agreed to go ahead with the relevant Fetch spec changes, adding the new headers to the Client Hints list as well as the CORS-safelisted request header list.So LGTM1, pending on said spec changes.
On Thu, Apr 26, 2018 at 8:34 AM Yoav Weiss <yo...@yoav.ws> wrote:On Tue, Apr 24, 2018 at 7:07 PM Tarun Bansal <tba...@chromium.org> wrote:The plan is to update the fetch spec and the Blink implementation to handle the new headers. Plan here (thanks Yoav!): https://github.com/whatwg/fetch/issues/707#issuecomment-383874881As far as the same origin policy is concerned, these headers should be treated similar to other currently existing client hints headers (dpr, width etc.). We plan to update the fetch spec to add the new headers: https://fetch.spec.whatwg.org/#terminology-headers, and then update the Blink implementation to conform with the spec.To be clear: you're planning to go ahead with the spec changes before shipping?Just had a chat with Tarun and he agreed to go ahead with the relevant Fetch spec changes, adding the new headers to the Client Hints list as well as the CORS-safelisted request header list.So LGTM1, pending on said spec changes.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a407fd25-9282-4235-91b8-9e4dbd57eaf4%40chromium.org.
We (Ojan, Yoav, Alex, Daniel, Rick) discussed this intent in the API owners meeting today. We agree with Anne's perspective that it's the responsibility of the chromium project to ensure we're precisely defining (via spec and test PRs) the behavior we're shipping, and therefore it's reasonable to block this intent on doing that (not just ask that people trust we'll get to it eventually). Thank you for raising your concern around this Anne!It seems likely that there's going to be a bunch of debate more on the editorial side (eg. which changes belong in fetch spec vs. html spec) and with minor details which are unlikely to results in real-world interop problems in practice, and that it's unlikely to be worth the cost to block shipping this feature on all of those questions. So the API owners expect we will be approving this intent based on unlanded pull requests we judge to be of sufficient quality. Yoav expects that he can get the PRs to this state in plenty of time to revisit this intent ahead of the M69 branch (July 19), and so this will ultimately translate into slipping this feature by one milestone as a result of these concerns.
Excellent, thanks for the progress! Tarun, when do you expect you'll be able to land the tests? I.e. should we circle back on this thread sometime before M69 branch? Note that if they refer to as-yet-unlanded specs, you can still land them in the WPT repo (eg. either exported from a chromium CL or direct in github) with a .tentative suffix.On Tue, Jun 26, 2018 at 1:47 PM Tarun Bansal <tba...@chromium.org> wrote:Yes, I am going to add the tests. crbug.com/852484 and crbug.com/856700 track the work.
On Tuesday, June 26, 2018 at 5:24:39 AM UTC-7, Yoav Weiss wrote:On Thu, May 24, 2018 at 8:51 PM Rick Byers <rby...@chromium.org> wrote:We (Ojan, Yoav, Alex, Daniel, Rick) discussed this intent in the API owners meeting today. We agree with Anne's perspective that it's the responsibility of the chromium project to ensure we're precisely defining (via spec and test PRs) the behavior we're shipping, and therefore it's reasonable to block this intent on doing that (not just ask that people trust we'll get to it eventually). Thank you for raising your concern around this Anne!It seems likely that there's going to be a bunch of debate more on the editorial side (eg. which changes belong in fetch spec vs. html spec) and with minor details which are unlikely to results in real-world interop problems in practice, and that it's unlikely to be worth the cost to block shipping this feature on all of those questions. So the API owners expect we will be approving this intent based on unlanded pull requests we judge to be of sufficient quality. Yoav expects that he can get the PRs to this state in plenty of time to revisit this intent ahead of the M69 branch (July 19), and so this will ultimately translate into slipping this feature by one milestone as a result of these concerns.Those unlanded PRs are now ready for review:https://github.com/whatwg/fetch/pull/725 - Tarun's PR, which adds the new hints to the list.https://github.com/whatwg/fetch/pull/773 - which aligns the spec with the implementation and initializes Fetch's client-hints list with the environment settings object one.https://github.com/whatwg/html/pull/3774 - which defines the ACHL cache, ACH and ACHL response header parsing and creates a new client-hints list on the environment settings object. It also defines the processing of the http-equiv header equivalents.
Reviewing the WPTs, I think there are a few missing:* Given where we landed on the privacy discussions, we need to make sure that ACH and ACHL do nothing when returned on a subresource response.* We also need to make sure the http-equiv variants of ACH and ACHL behave the same as their header variants.
Tarun - will you be able to take on adding those tests?Anne seems to be OOO up until the M69 branch, so we probably should not hold off on his reviews. The overall design is based on a discussion I had with him before, so I don't expect a huge amount of changes. I also commit to follow-up on those PRs with any reasonable changes that will be required.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_Wv1nMHX6HGV_ycoLRgK2%3D6c6B2zn%3Da--M0Q%2BEBCcrdQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEgG9d%2Bnuk88Ngz24%3DGrB4qfTpVQ5Ght_ghhQKphQhLAgQ%40mail.gmail.com.
Agreed with one caveat - it's both reasonable spec AND test changes in the pipeline that I think we want to see. So I'd still like to see a discussion on what amount of test work folks feel should block this intent. Obviously test coverage is never perfect, but what's a reasonable amount of coverage in WPT (even as "tentative tests") before we feel comfortable saying we've provided enough tests to provide likely real-world interoperability with future implementations?Yoav / Tarun, what's your opinion?
Rick
API owners, PTAL?
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_Wv1nMHX6HGV_ycoLRgK2%3D6c6B2zn%3Da--M0Q%2BEBCcrdQ%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEgG9d%2Bnuk88Ngz24%3DGrB4qfTpVQ5Ght_ghhQKphQhLAgQ%40mail.gmail.com.
Rick
API owners, PTAL?
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_Wv1nMHX6HGV_ycoLRgK2%3D6c6B2zn%3Da--M0Q%2BEBCcrdQ%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEgG9d%2Bnuk88Ngz24%3DGrB4qfTpVQ5Ght_ghhQKphQhLAgQ%40mail.gmail.com.
--/* Opera Software, Linköping, Sweden: CEST (UTC+2) */
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/209f5aad-62af-4666-9ec3-cc03bf9bc90f%40chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-d1T9FvHsokUowvLWGNx0ZTi9LKgenU23inkegKDTE3w%40mail.gmail.com.
On Tue, Jul 3, 2018 at 10:31 AM, Rick Byers <rby...@chromium.org> wrote:LGTM3 to ship as reasonable test coverage lands.Chris, above Yoav was talking about not blocking shipping on AnneVK getting back from vacation and reviewing the PRs he has (which he feels are complete). Is that OK with you?
Yes, that's ok by me.
LGTM3 to ship as reasonable test coverage lands.Chris, above Yoav was talking about not blocking shipping on AnneVK getting back from vacation and reviewing the PRs he has (which he feels are complete). Is that OK with you?
Rick
API owners, PTAL?
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_Wv1nMHX6HGV_ycoLRgK2%3D6c6B2zn%3Da--M0Q%2BEBCcrdQ%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEgG9d%2Bnuk88Ngz24%3DGrB4qfTpVQ5Ght_ghhQKphQhLAgQ%40mail.gmail.com.
--/* Opera Software, Linköping, Sweden: CEST (UTC+2) */
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/209f5aad-62af-4666-9ec3-cc03bf9bc90f%40chromium.org.