Subject: [httpwg/http-extensions] Scoping of Accept-CH (#307)

From: HTTP issue updates <[email-masked]>
Date: Wed, 01 Mar 2017 20:09:41 -0800

The `Accept-CH` response header is defined as:

> When a client receives Accept-CH, or if it is capable of processing the HTML response and finds an equivalent HTML meta element, it can treat it as a signal that the server is interested in receiving the Client-Hint header fields that match the advertised field-values; subsequent requests initiated to the same server and, optionally any subresource requests initiated as a result of processing the response from the server that includes the Accept-CH opt-in, can include the Client-Hint header fields that match the advertised field-values.
>
> For example, based on Accept-CH example above, a user agent could append DPR, Width, Viewport-Width, and Downlink header fields to all subresource requests initiated by the page constructed from the response. Alternatively, a client can treat advertised support as a persistent origin preference and append same header fields on all future requests initiated to and by the resources associated with that origin.

"All future requests" is a long time indeed. While of course the client isn't going to literally do that (eventually it'll be garbage collected, or the user will reset state, or the machine will be recycled), from a server-side perspective, it'd be nice to have *some* level of control over how bloated your requests get.

Additionally, having `Accept-CH` possibly indicate that future references *to* **and** *from* this origin seems like a pretty broad brush to be painting with. While Chrome might make some reasonable decisions about tradeoffs here (and probably needs some wiggle room), if this ever does get implemented elsewhere, this broadness and freedom is a recipe for bad interop and worse server-side headaches.

So, can we nail this down at all? 

The most conservative approach is:

"Send CH headers on subrequests generated by this content, please."

However, the above also says "subsequent requests initiated to the same server" in the primary spot; the case above is relegated to "optionally."

Personally, my preference would be to drop "subsequent requests initiated to the same server and, optionally" and the corresponding text in the example below it. The primary use case for CH as I understand it is serving appropriate subresources, NOT dynamically modifying HTML, so that should do the trick.

Am I missing something, @igrigorik?

Regardless of that, "server" is used very loosely above; I think you mean "origin", right? And "can" should probably be "MAY".

CC @yoavweiss

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/307