Re: [w3ctag/design-reviews] `Accept-CH` header is weird (#206)

I feel like we're going in circles here, and it's frustrating..

> Discussed at London F2F. TAG's group conclusion is that this header needs to be reconsidered. Our primary concern is the redirection that it incentivises. We believe many sites will choose to bounce non-bot users through a redirect in order to farm the CH data before rendering a first page. As the number of CH headers increases, this motivation will only get stronger. There is a strong precedent for web authors doing things that implementors think are bad ideas (eg. naive user agent header parsing).

As stated before, CH is *progressive enhancement*. Your position is premised on the fact that every hint must be available on every request, from every browser. This will **never be true** for reasons stated earlier, nor does it account for the very real concerns of overflowing window sizes.

Further, as explained earlier, the combination of Accept-CH + Accept-CH-Lifetime gets us to exactly the same place you're looking for, but addresses the above. Delivery of every hint on every request, without an opt-in, is an non-starter for implementers — I've pushed this rock up this particular hill for 5+ years now, I can say this with certainty. 

Last but not least, we've had CH in production (without delivery on initial request) for a few years now and yes, we heard loud and clear feedback that sites want it on initial request. However, nothing stopped implementers from using the redirect pattern you've described.. and yet, I'm not aware of a single instance of this. On the other hand, we have strong feedback that Accept-CH + Accept-CH-Lifetime is a good solution that would be used once available. 

> It's worth noting that there are numerous examples of major sites doing redirects on a first request. 

Yes, redirects are a thing, and? Are you suggesting that web should get rid of redirects? If so, that's a separate TAG discussion.

> And also that many site authors will go to considerable lengths to avoid an inconsistent experience between the first and second page views. 

Progressive enhancement is a thing — e.g. ServiceWorker. Does the TAG believe that progressive enhancement is a pattern that we should discourage on the web? How did we rationalize SW?

> if subresource requests within a page get different CH headers to the page itself, the subresources run the risk of not being compatible with the page into which they are being loaded.

How does this relate to any of the above, and what makes you believe that subresource requests would receive different hints? The opt-in is origin wide. 

---

Just to be clear, I _understand and hear_ the raised concerns here. The challenge is that the solution space here has tradeoffs on all sides, and I strongly believe — based on past 5+ years of work on this — that given the feedback from browser/client+server+site implementers we've arrived at a good solution that satisfies all the parties. Would everything be simpler if we could just send every hint on every request — of course, that's where we started! But for all the reasons stated above, that's not a tenable solution. 

If the TAG has an alternative proposal that can satisfy all of the issues raised above, I'm happy to hear it. In absence of one, "reconsider" is not useful feedback.


-- 
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/206#issuecomment-362725042