Accept-CH+Lifetime opt-in is for same-origin resources #656
Conversation
Per discussions in fetch#726 [1], update the opt-in example to apply to same-origin resources only, with Accept-CH-Lifetime being processed on navigation requests. [1] whatwg/fetch#726 (comment)
| @@ -148,7 +148,7 @@ The preference MUST be delivered over a secure transport, and MUST NOT be persis | |||
| Accept-CH-Lifetime: 86400 | |||
| ~~~ | |||
|
|
|||
| For example, based on the Accept-CH and Accept-CH-Lifetime example above, which is received from "https://bar.example.com" in response to a resource request initiated by "https://foo.example.com", both delivered over a secure transport: a user agent SHOULD persist an Accept-CH preference bound to "https://foo.example.com", for requests initiated to "https://bar.example.com" from "https://foo.example.com", for up to 86400 seconds (1 day). This preference SHOULD NOT extend to requests initiated to "https://bar.example.com" from other origins. | |||
| For example, based on the Accept-CH and Accept-CH-Lifetime example above, which is received in response to a user agent navigating to "https://example.com", and delivered over a secure transport: a user agent SHOULD persist an Accept-CH preference bound to "https://example.com" for up to 86400 seconds (1 day), and use it for user agent navigations to "https://example.com" and any same-origin resource requests initiated by the page constructed from the navigation's response. This preference SHOULD NOT extend to resource requests initiated to "https://example.com" from other origins. | |||
There was a problem hiding this comment.
I think this example works, but would be good to also include the same rules in the processing definition above. e.g. s/When a client receives an HTTP response/When a client receives an HTTP navigation response, which is the same origin as the request which initiated the navigation/
Would such a language work for non-browser scenarios?
There was a problem hiding this comment.
Would such a language work for non-browser scenarios?
My hunch is "no" and we shouldn't impose this restriction here / scope it to browsers only. UA's have a concept of user-initiated "navigation", but this doesn't extend to other potential clients — e.g. a native app using CH negotiation with a CDN should be able to define own logic for how to process the opt-in; FP doesn't apply for other clients.
My suggestion is to keep the text as is, otherwise we'll quickly find ourselves redefining HTML concepts, which we should instead defer to the HTML spec.
WDYT?
There was a problem hiding this comment.
OK, so the normative text is for all clients and the examples is UAs only? I guess that makes sense.
There was a problem hiding this comment.
Yep, that's how we've structured it so far.
That aside, good to merge?
Per discussions in fetch#726 [1], update the opt-in example to apply to
same-origin resources only, with Accept-CH-Lifetime being processed on
navigation requests.
[1] whatwg/fetch#726
/cc @yoavweiss @tarunban