Request for position: aligning on <link rel=prefetch>

[noamr]

Request for position on an emerging web specification

(Please delete inapplicable rows.)

• WebKittens who can provide input:

Information about the spec

• Spec Title: Prefetch processing model
• Spec URL: Define link processing for prefetch whatwg/html#8111
• GitHub repository: https://github.com/whatwg
• Issue Tracker (if not the repository's issue tracker):
• Explainer (if not README.md in the repository):

Design reviews and vendor positions

• TAG Design Review:
• Mozilla standards-positions issue: Aligning on behavior of prefetch mozilla/standards-positions#723

Bugs tracking this feature

• WebKit Bugzilla: https://bugs.webkit.org/show_bug.cgi?id=194539
• Radar: rdar://3176096

Anything else we need to know

Some details in the proposal to align over:

• Prefetch is essentially designed to populate the HTTP cache at low priority, for subsequent navigations and resource loads.
• The Accept header for prefetch is defined as the same one that is sent with frame navigation. This prevents double-prefetches with Vary: Accept. See Accept header for prefetch whatwg/fetch#1485
• Sending Sec-Purpose for prefetches, to allow servers to discern between regular requests and resource hints. See Send Sec-Purpose: prefetch header for prefetch requests whatwg/fetch#1576
• Using "least restrictive" CSP directive. See Use "least restrictive" directive instead of prefetch-src w3c/webappsec-csp#582

[othermaciej]

Defining how prefetch works with http cache partitioning (in a way that is not a privacy violation and does not result in duplicate loads) is a hard blocker for us supporting it. The issue is described at w3c/resource-hints#82 but remains unfixed. Current plan seems to be to address this as part of a larger rewrite: w3c/resource-hints#86 (comment) but that seems to be stalled.

Without spec text addressing this it’s hard for us to meaningfully evaluate this since the current spec only allows either enabling tracking or making prefetches useless.

[noamr]

Defining how prefetch works with http cache partitioning (in a way that is not a privacy violation and does not result in duplicate loads) is a hard blocker for us supporting it. The issue is described at w3c/resource-hints#82 but remains unfixed. Current plan seems to be to address this as part of a larger rewrite: w3c/resource-hints#86 (comment) but that seems to be stalled.

Without spec text addressing this it’s hard for us to meaningfully evaluate this since the current spec only allows either enabling tracking or making prefetches useless.

The spec text in whatwg/html#8111 is very specific about it: <link rel=prefetch> is not meant for cross-origin navigations - only for same-origin navigations and same-partition subresources.

The work on cache partitioned prefetch is worked on in parallel, see #54.

[domenic]

Yes, I'd really urge WebKit to pay attention to the difference between subresource prefetch (this issue, and the linked spec therein) which is totally unproblematic, and navigational prefetch (#54, and the linked spec therein) which requires more care. In both cases, we think we've done the work! But please evaluate the work, instead of assuming what's designed is non-private or that the spec text is lacking.

[noamr]

Added a comment in the linked spec issue. @annevk, I'm confused as this is different from what you said here. I feel there's some misunderstanding here, would you be able to help?

[annevk]

Yeah, I think this is an acceptable model.

To elaborate, the HTML PR does not define its own cache and relies completely on the fetch algorithm. That algorithm takes care of partitioning all network state. As such prefetches will only be useful if they end up being hit in the same partition by a regular fetch later on.

I chatted with Maciej and he agreed, so I’ll resolve this as “position: support” seven days from now.

[othermaciej]

I agree with Anne. I previously was confused about the state of the discussion; it seems like the HTML PR supersedes those older PRs and issues that I linked to.

It seems like the new design will not violate partitioning, so that's from a privacy POV. It will make <link rel=prefetch> useless for navigation prefetch, but Anne says we have indications that this would not lead to significant wasteful double-fetches.

[noamr]

I agree with Anne. I previously was confused about the state of the discussion; it seems like the HTML PR supersedes those older PRs and issues that I linked to.

It seems like the new design will not violate partitioning, so that's from a privacy POV. It will make <link rel=prefetch> useless for navigation prefetch, but Anne says we have indications that this would not lead to significant wasteful double-fetches.

Thanks for re-reviewing! Small correction: <link rel=prefetch> useless for cross-origin/cross-site navigation prefetch (depending on partitioned cache etc), but is totally OK for same-origin navigational prefetch.

[dieulot]

To reiterate from the WebKit issue, as someone making a library (instant.page) that uses navigational prefetch, I know it would be totally fine if Safari implemented only same-origin navigational prefetch and cross-origin navigational prefetch was a noop. It’s progressive enhancement, so a “partial implementation” (the meat of it) would not be “poorly received”. Unlike the complete, silent, ever-present, unique-to-WebKit lack of implementation has been.

[othermaciej]

To reiterate from the WebKit issue, as someone making a library (instant.page) that uses navigational prefetch, I know it would be totally fine if Safari implemented only same-origin navigational prefetch and cross-origin navigational prefetch was a noop.

I'm not sure this is possible. Can cross-site navigational prefetch be distinguished from cross-site subframe resource prefetch?

[annevk]

No it cannot. I'm not sure what @dieulot means as the behavior proposed here would be the same in all browsers. If that library attempts to prefetch cross-origin navigations that would be wasted bandwidth in all browsers as they would all constrain usage thereof to the current partition.

[dieulot]

My message was about “unlocking” WebKit/Safari’s implementation — a case against spec compliance purity. It’s a response to Maciej’s third paragraph in webkit.org/b/194539#c10.

Can cross-site navigational prefetch be distinguished from cross-site subframe resource prefetch?

Now that the as attribute is officially no more, it turns out no distinction between any type of intended usage can be made.
Even so, shipping same-origin prefetch only, for any type of content, would be beneficial — if interaction with cache partitioning is still a large part what is blocking WebKit.

[hober]

Closing as we've identified our position.