Re: [w3ctag/design-reviews] Review request for Device Memory API (#190)

Thanks for the feedback!

> Which requests are eligible for getting the header? All requests? 

Yes - all requests. This is the same as what applies to Client Hints in general, we are not restricting request type for Device Memory.
Suggestions here are welcome, but would likely apply to Client Hints in general.

> What's the anticipated behavior of the navigator.deviceMemory API when the Accept-CH = Device-Memory header isn't set?

navigator.deviceMemory API will work even without Accept-CH header (for HTTPS secure contexts only). The usecase for navigator.deviceMemory API is bit different from the header - the API will be used by analytics for device class and for normalizing metrics against etc.

> For consistency, do you anticipate also extending the hardwareConcurrency information with a similar header?

Yes. @n8schloss is planning to drive this work.

> Why is sending this header restricted to requests that have the Accept-CH header? If the response value is restricted (e.g. to top-level navigation requests), it seems like requiring the opt-in will just add more bloat for production services (like Google) that are likely to query for this data pervasively.

The opt-in with Accept-CH is needed to avoid request overhead / bloat from sending lots of uninteresting headers that are not useful or needed.
Most apps will need this header on the very first request (eg. to serve Google Search Lite), and the Accept-CH-Lifetime addition addresses this need:
http://httpwg.org/http-extensions/client-hints.html#accept-ch-lifetime

> Have there been discussions about how related values (e.g., video memory) might be surfaced?

Not yet. Developers have not yet requested this AFAIK.

\cc @fmeawad

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/190#issuecomment-332945116