On Thu, Jul 28, 2016 at 11:18 AM Mike West <mkwst@google.com> wrote: > On Thu, Jul 28, 2016 at 6:00 PM, Brad Hill <hillbrad@gmail.com> wrote: > >> One more suggestion. If the client tells the server it has "v10.0.1" and >> the server is OK with that but has "v10.0.2" available, it would be nice if >> the server could reply with: "Origin-Policy: v10.0.2; async", (or >> something) which tells the client, don't block on loading the new policy >> for this request, but queue a task to update your policy to the new one >> asynchronously. For something like a "Like" button (or an ad) where TTI >> is really important, we would love the transfer savings this could provide, >> but also probably very rarely if ever want to block for a synchronous >> update unless the client doesn't have a policy at all. >> > > Huh. I'd only thought about this as an all-in synchronous system, or a > TOFU-style system. It didn't occur to me that the developer might actually > be best positioned to make that decision. :) > I can’t recall if this was discussed before or not. But, how often do we expect 1) Baseline policies to change (I’m not talking about folks that want dynamic additions on specific endpoints) 2) People to need instant updates to their baseline policy In other words, I wonder how often this `async` might be fine as the normal course of events for when a policy changes. A more general way to approach this is a `max-age` directive. Assuming most sites would be fine with some window to roll out changes to their policies, then it could be up to the browser to fetch a new version when convenient. And, if a site really wants to force an updated policy, an potentially incur a synchronous delay , they can send down some sort of `max-age: 0` with their response. > > It should be pretty straightforward to extract the relevant logic out into > an operation that could be performed asynchronously, though we'd need to be > clear about the promises we're making about the current navigation and the > resources it loads in that scenario (namely: none). > > Would you mind filing a bug against the draft? I'll add something like > this in tomorrow. > > -mike >
Received on Thursday, 28 July 2016 17:34:38 UTC