hey folks, Looking at this in API OWNERS this morning, I wasn't able to see an obvious developer opt-out. The spec and explainer talk about letting the server opt-out, but it appears that the primary way that would happen is aborting a response. This is a potentially expensive and surprising for servers. Has there been any thought about supporting a response header that would allow a response document to opt into, e.g., only prefetch behavior but not prerendering?
Best Regards, Alex On Wednesday, February 16, 2022 at 12:44:53 AM UTC-8 [email protected] wrote: > I created an issue specifically for the BroadcastChannel discussion: > https://github.com/WICG/nav-speculation/issues/141 > > We'd love to hear if there are other issues with restrictions (or other) > that need addressing! > Browse/open at https://github.com/WICG/nav-speculation/issues > > On Monday, February 14, 2022 at 6:38:40 PM UTC+2 [email protected] > wrote: > >> On Mon, Feb 14, 2022 at 11:33 AM Noam Rosenthal <[email protected]> >> wrote: >> >>> >>> >>> On Saturday, February 12, 2022 at 7:11:29 AM UTC+2 [email protected] >>> wrote: >>> >>>> I agree with Domenic that it's great to see this kind of feature, that >>>> was traditionally unspecified, getting some clearer developer visibility >>>> and a spec. While there may still be missing pieces, this seems like a >>>> good >>>> start. I'm looking forward to further spec discussions that would >>>> hopefully >>>> lead to convergence and better interop. >>>> >>>> On Fri, Feb 11, 2022 at 11:39 PM Domenic Denicola <[email protected]> >>>> wrote: >>>> >>>>> >>>>> >>>>> On Fri, Feb 11, 2022 at 11:53 AM Olli Pettay <[email protected]> >>>>> wrote: >>>>> >>>>>> FWIW, the comment in the HTML spec triage was positive feedback to >>>>>> have a spec for this. >>>>>> The current spec proposal clearly is missing still quite a few cases >>>>>> (is the idea really that one can use BroadcastChannel with prerendered >>>>>> page? and the webidl annotation behaves rather oddly) >>>>>> So it is surprising to see this shipping already now. >>>>>> >>>>> >>>>> Thanks for chiming in, Olli! >>>>> >>>>> I have a rather different take. As the team's spec mentor, I'm >>>>> impressed with the spec work the team has done, on taking what most other >>>>> browsers have treated as a not-to-be-specified user agent UI feature, and >>>>> turning it into something much more rigorous and developer-friendly. For >>>>> example: >>>>> >>>>> - The careful auditing of all APIs to see how they should behave >>>>> in prerendering. >>>>> - Introducing a well-specified Sec-Purpose: prefetch header, >>>>> instead of the unspecified X-moz: prefetch or X-Purpose: preview >>>>> headers. >>>>> - Considering how to handle edge cases such as redirects, 204s, >>>>> Content-Disposition: attachment, or pages that do client-side >>>>> navigation >>>>> while being prerendered. >>>>> >>>>> I think there's definitely still work to be done, as we try to move >>>>> from the current world where every browser does something different into >>>>> one that's more fully predictable for web developers. But I think this is >>>>> similar to other features, like bfcache, where for many years the >>>>> heuristics and rules used were unspecified (e.g. Cache-Control, unload >>>>> handlers, BroadcastChannel), and then we've started a slow convergence >>>>> process as browsers start to care more about interoperability. >>>>> >>>>> We can definitely tweak things, like Olli's example of >>>>> BroadcastChannel, over time and as other browsers indicate willingness to >>>>> converge. >>>>> >>>> >>>> One potential problem with that approach is that sites may grow to rely >>>> on that existence of e.g. BroadcastChannel and may break when we take that >>>> away. >>>> I don't think that's a risk for the current I2S, as developers are not >>>> aware that the page is being prerendered outside of the page itself, so >>>> the >>>> chances of them trying to communicate with it are low. >>>> But that can be a risk for the speculation rules based API, which would >>>> be good to mitigate. >>>> >>>>> >>>>> Re. BroadcastChannel and friends - it's a totally valid point and >>> there's an open issue about it ( >>> https://github.com/WICG/nav-speculation/issues/113). I feel that we >>> should examine these especially as we move from omnibox to >>> document-initiated prerenering. >>> >> >> Yeah, just to be clear, I agree page-initiated prerendering multiplies >> the risks significantly and will thus need more work. I expect there will >> still be some implementation-dependent behavior (e.g., some implementations >> may discard a prerender if they use a disruptive API, while others might >> delay the API results). But things like "does BroadcastChannel work at all >> or not" are critical to nail down for interoperable page-initiated >> prerendering. >> >> > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f2b5479c-7146-45f4-a713-b426a0b2327dn%40chromium.org.
