Expose "Save-Data" client hint in navigator.connection

[jeffposnick]

The Save-Data client hint (described here in more detail by @igrigorik), exposes information that would be useful outside of the context of handling a HTTP request. For instance, a service worker might use the client hint to determine, as part of its install handler, whether to precache a heavy- or lightweight bundle of resources.

Exposing this information from within the NetworkInformation interface means that a service worker and other scripts could access it via navigator.connection.

[igrigorik]

That's a good use case. My proposal would be to expose:

interface NetworkInformation : EventTarget {
    readonly attribute DOMString saveData;
};

The value would contain the token communicated in the Save-Data header. Today this would yield a single value of "on", but the IETF spec does allow us to define other token values and we should support that here as well.

/cc @marcoscaceres @jkarlin

[marcoscaceres]

I wonder if one could just get the Save-Data client hint from the outgoing Request? That may allow modification of the Request's URL if need be upon the SW fetch event on a per Request basis without the need to expose this in the API.

The decision about what to store in the cache is generally made on "environmental conditions" and those are not enforceable with Save Data (unlike with something akin to Content Performance Policy).

The risk is that this signal is of limited value because it's not enforceable (similar to DNT) - which may end up confusing or frustrating user who set this, but then just get ignored by sites.

[jeffposnick]

Just to clarify something from @marcoscaceres's previous comment, this information would be most useful if it were available inside of a service worker's install handler, which is the event that's normally associated with precaching.

There's no Request exposed in the InstallEvent that's passed to the install handler.

[bengreenstein]

@igrigorik's proposed extension to NetworkInformation sounds great to me for the reason already mentioned by @jeffposnick (for SW decision making related to precaching). I can see it also being a good signal for adaptive video libraries to degrade quality somewhat to reduce network data use.