Following on from #190, the Accept-CH header seems strange. We're trying to understand its motivation.

The latest draft spec notes cache-friendliness as a reason for the header. This motivation isn't entirely clear; aren't servers allowed to specify which headers to Vary on?

Other reasons we have heard include header bloat, but this hasn't been quantified for us. I.e., if a large fraction of high-traffic sites opt-in via Accept-CH, it seems probable that Accept-CH + DPR, Width, etc. data would be larger than simply sending all values all the time.

Lastly, it doesn't seem that there's a privacy motivator, given that this is a server opt-in.

This design complicates some scenarios and makes it harder to design new APIs. If header bloat is a major issue for the platform, the TAG would also like to be aware so as to help avoid designs that would encourage the addition of new headers. As yet, this case hasn't been clearly articulated with data we've seen.

Please help, @mnot, @triblondon, @igrigorik!