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

> There's a deep principle I'd like some clarity on: are we "too bloated" today? It seems the primary value is in reducing request header size, but only on the sites which don't use the values subsequently. This is very concerning! It seems that if we're at (or beyond) some theoretical limit about the total amount we can add, that the TAG should be providing strong guidance to feature developers to avoid new header information and perhaps be working to trim existing bloat back. If that's a cause we need to be signed up to, we'd love to know.

Every new TCP connection starts with a small send+receive window — see [flow control](https://hpbn.co/building-blocks-of-tcp/#flow-control) & [congestion control](https://hpbn.co/building-blocks-of-tcp/#congestion-avoidance-and-control). As a result, if the client overflows the initial window, it'll incur extra roundtrips before the request can be read and processed by the server. Historically, this value was only 3 packets, and RFC 6928 bumped it to 10 packets. I don't have recent telemetry on adoption of IW10, but let's assume that most clients and servers are using this new limit. Even so, ~14KB does not offer infinite room for growth, especially once you account for large cookies, long URLs, etc.

As a result, the general guidance is to be conservative with adding headers that are emitted by default: omit if possible, use compact form, make them opt-in, etc. That's not a hard and fast rule against adding headers, but a good guiding principle that's true today and will stay true in the future.

_As a side note: HTTP/2 helps a bit here with its default dictionary allowing us to compress common header fields, but the client still has to communicate the initial non-default values (e.g. all cookie values, etc) at the start of the connection, so overall calculus stays the same._


> Specifically, would love to understand if there's data that points to a general issue with header bloat and a calculus that describes how the Accept-* pattern helps, particularly given the extra round-trips that might be needed (e.g., for a redirect) to generate alternative body content for a top-level request.

As outlined above, we don't have infinite room for growth if we want to avoid bumping against the initial window size and incurring extra roundtrips. On the other hand, the goal of Client Hints is to establish a _framework_ that can allow us to communicate an easily extensible list of hints (well beyond what's in the spec today), some of which may only be useful to a select number of origins. 

Hence the opt-in flow provided by Accept-CH. The server indicates to the client which hints it is interested in, alongside an optional preference for how long the client should remember this preference for, and the client can then emit the right hints for each origin without burdening the web at large with every hint we can think of ever.

---

> Does the data suggest that we should be trying to consolidate Accept-* headers? If we're over our budget, would like to avoid opt-in-flag bloat.

No. Modifying default Accept header is something we've historically been very-very careful with, not for reasons of size but due to fear of triggering invalid matches in existing Accept parsers in the wild. A separate Accept-CH header provides clean separation from this problem at a cost of 9 extra bytes — bytes well spent.

Conversely, you also want to deliver hints as separate headers, instead of a single glob value, because the latter is not cache friendly and makes it very hard to craft Vary/Key policies.

---

> Fundamentally the request-response model of the web is built on the idea that each transaction is relatively stateless, and I'm uneasy about the recent trend to bend those rules with stuff like Clear-Site-Data or HSTS which apply to the entire origin or affect subsequent requests. Origin policy seems like the answer to this concern, and it seems at the very least a shame to ship Accept-CH in the meantime.

"Relatively stateless" is a nice myth — see cookies. I hear your concerns but the mechanism we're using here is using well-established HTTP semantics. If and when Origin Policy becomes available, we can certainly look into enabling CH through it for browsers, as an alternative deployment option. Don't forget that CH is _not_ restricted to browsers only, it's also useful to other types of clients to whom OP does not appy, but also benefit from a standard negotiation mechanism provided by Accept-CH. Not to mention, OP also introduces blocking roundtrips, which are highlighted below as a potential concern.

---

> We noted that there's a danger of sites introducing a mandatory redirect for non-bot users just to capture the CH data before rendering a page. Some sites for example might have a very different experience when Save-Data is enabled (see CNN vs CNN lite).

That's bad implementation. CH is progressive enhancement: you can't assume that all browsers will provide all of the hints all the time — e.g. some browsers may not support some hints at all, some may opt-out from sending them when in incognito, and so on. In other words, think of CH in the same way as you think about ServiceWorker registrations. Is it possible that some sites might choose to wait for the SW registration and force a reload? Yes. But, once again, that's bad implementation. CH is subject to same considerations and best practices:

- Server should check for presence of hints on the nav request.
  1. If hints are present, because of previous opt-in: use them
  1. Otherwise, emit Accept-CH + Accept-CH-Lifetime
     - If the browser supports delivery of requested hints, it will deliver them on subsequent requests to the origin (nav requests, subresource requests, etc) — see (i)

---

I believe this should address all the outstanding questions here. Let me know if I missed anything.

-- 
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-361278414