Update prefetch link once the spec and implementations are finalized

[noamr]

MDN URL

https://developer.mozilla.org/en-US/docs/Glossary/Prefetch

What specific section or headline is this issue about?

No response

What information was incorrect, unhelpful, or incomplete?

The current text accurate-ish to the current Firefox implementation, but that's about to change:

• Use Sec-Purpose instead of Purpose or x-moz
• Accept header is the same as the one for regular address-bar browsing
• CSP: uses "least restrictive directive" rather than prefetch-src

What did you expect to see?

I expect the page to reflect how prefetch works in an interoperable way (once reality catches up with that...)

Do you have any supporting links, references, or citations?

See HTML PR: whatwg/html#8111

Do you have anything more you want to share?

No response

[hamishwillee]

FYI, FF supports Sec-Purpose: prefetch from FF115 so I will be trying to document that shortly in #27171.

@noamr It would be good to have help writing a vendor neutral version of https://developer.mozilla.org/en-US/docs/Glossary/Prefetch if you have advice.

I also found this doc, which I think should be deleted: https://developer.mozilla.org/en-US/docs/Web/HTTP/Link_prefetching_FAQ

[noamr]

FYI, FF supports Sec-Purpose: prefetch from FF115 so I will be trying to document that shortly in #27171.

Amazing.

@noamr It would be good to have help writing a vendor neutral version of https://developer.mozilla.org/en-US/docs/Glossary/Prefetch if you have advice.

Yes it would be great! I suggest starting with the spec, and ask if anything is missing/needs clarifying?

I also found this doc, which I think should be deleted: https://developer.mozilla.org/en-US/docs/Web/HTTP/Link_prefetching_FAQ

[hamishwillee]

@noamr Thanks. I also found your comment here useful https://bugzilla.mozilla.org/show_bug.cgi?id=1788167 as that seems to summarize where browsers/servers should end up.

[noamr]

@noamr Thanks. I also found your comment here useful https://bugzilla.mozilla.org/show_bug.cgi?id=1788167 as that seems to summarize where browsers/servers should end up.

Yes, though "When consuming prefetch, Vary: Accept should be ignored" is unnecessary if the accept header is the same as navigation. That's what we ended up doing in chrome and WPT (Send the same accept header as nav, but don't treat it in a special way when invalidating cache)

[hamishwillee]

@noamr Can you confirm my understanding of the CORS-mode behaviour - specifically what does this mean?:

CSP: uses "least restrictive directive" rather than prefetch-src

Looking at the spec https://w3c.github.io/webappsec-csp/#does-request-violate-policy ...

Given a request request and a policy policy, this algorithm returns the default directive if the resource-hint request violates all the policies, and "Does Not Violate" otherwise.

So in other words you run the test against all the policies and only fail if all of them fail. Is that right?

Further, that means if default-src is not specified (everything is allowed) you will succeed. And if default-src is permissive, the fact that others are not does not matter.

And presumably same-site requests just work?

[hamishwillee]

Also,

1. This test indicates that "Prefetch should include Sec-Purpose=prefetch and Sec-Fetch-Dest=empty headers"

2. So does as in a link map to the destination the value set by Sec-Fetch-Dest? So the above means that irrespective of the data type you'd just not specify the destination.

3. But then in this test we have:

   • same origin document prefetch without 'as' should be consumed
   • same-site different-origin document prefetch without 'as' should be consumed
   • different-site document prefetch without 'as' should not be consumed
   • different-site document prefetch with 'as=document' should not be consumed

   This confuses me if the Sec-Fetch-Dest passes the data from link as and that must be empty. It seems to indicate that that same site prefetch of a document doesn't need as (always succeeds), but cross-site document prefetches of documents do not.

I'm probably asking a stupid question here sorry, but what are the rules for "as", and are there special rules for document/cross-site and so on.

[noamr]

@noamr Can you confirm my understanding of the CORS-mode behaviour - specifically what does this mean?:

CSP: uses "least restrictive directive" rather than prefetch-src

Looking at the spec https://w3c.github.io/webappsec-csp/#does-request-violate-policy ...

Given a request request and a policy policy, this algorithm returns the default directive if the resource-hint request violates all the policies, and "Does Not Violate" otherwise.

So in other words you run the test against all the policies and only fail if all of them fail. Is that right?

Yes. The idea is that your prefetch could be any type of resource. So if any type of resource is allowed to be fetched from this URL, you can also prefetch this URL.

Further, that means if default-src is not specified (everything is allowed) you will succeed. And if default-src is permissive, the fact that others are not does not matter.

Correct.

And presumably same-site requests just work?

No, you can also prevent same-site in CSP.

[noamr]

Also,

1. This test indicates that "Prefetch should include Sec-Purpose=prefetch and Sec-Fetch-Dest=empty headers"
2. So does as in a link map to the destination the value set by Sec-Fetch-Dest? So the above means that irrespective of the data type you'd just not specify the destination.

It does in <link rel=preload>. There is no as in prefetch.

3. But then in this test we have:

   • same origin document prefetch without 'as' should be consumed
   • same-site different-origin document prefetch without 'as' should be consumed
   • different-site document prefetch without 'as' should not be consumed
   • different-site document prefetch with 'as=document' should not be consumed

   This confuses me if the Sec-Fetch-Dest passes the data from link as and that must be empty. It seems to indicate that that same site prefetch doesn't need as, but cross-site document prefetches do.

I'm probably asking a stupid question here sorry, but what are the rules for "as", and are there special rules for document/cross-site and so on.

The as=document is some non-standard thing in chromium that we will remove in the future. These tests show the desired results: that as=document doesn't do anything special. they currently fail on chromium because of the special behavior.

[Josh-Cena]

@noamr Do you think this could be closed by #27589?

[noamr]

@noamr Do you think this could be closed by #27589?

Yes!

[Josh-Cena]

Wow, thanks for the prompt response 😄

[hamishwillee]

@noamr ... and thanks for all your support on getting the fixes in.