New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add prefetch processing model, including double-key caching privacy protections #4115

Open
wants to merge 2 commits into
base: master
from

Conversation

4 participants
@yoavweiss
Copy link
Collaborator

yoavweiss commented Oct 23, 2018

This closes w3c/resource-hints#82 in order to:

  • Define a processing model for prefetch.
  • Define a way for prefetch to work nicely for double-keyed caching browsers, without enabling ways for different origins to communicate and persist information in the browser.

@annevk @domenic - I handwavily talk about cache keys here. Let me know if that works, and if you want me to add a note/issue about better defining that (and double keying) in the future.

I think that the second part of w3c/resource-hints#82 would be to define what a "speculative fetch" is (as a Fetch primitive), and sat that browsers can choose to never fetch them, and should keep them in a non-partitioned, time-limited cache.


/infrastructure.html ( diff )
/semantics.html ( diff )

yoavweiss added some commits Oct 23, 2018

@yoavweiss

This comment has been minimized.

Copy link
Collaborator

yoavweiss commented Oct 23, 2018

@youennf @kinu - could you take a look and let me know what you think?

<li><p>If <var>request</var>'s <span data-x="concept-request-referrer-policy">referrer policy</span> is not "no-referrer", then return.</p></li>
<li><p>If <var>request</var>'s <span data-x="concept-request-destination">destination</span> is not "document", then return.</p></li>
<li><p>Set <var>request</var>'s <span data-x="concept-request-redirect-mode">redirect mode</span> to "manual".</p></li>
<li><p>Set <var>request</var>'s <span data-x="concept-request-redirect-mode">redirect mode</span> to "manual".</p></li>

This comment has been minimized.

@youennf

youennf Oct 23, 2018

Duplicated line

<var>as</var>.</p></li>
<li>If the browser is using both the <var>request</var>'s <span data-x="concept-request-url">URL</span> and the <span data-x="top-level-browsing-context">top-level browsing context</span>'s <span data-x="document">document</span>'s <var data-x="dom-document-origin">origin</span> as cache keys for <var>request</var>, then:
<ol>
<li><p>If <var>request</var>'s <span data-x="concept-request-credentials-mode">credentials mode</span> is "include", then return.</p></li>

This comment has been minimized.

@youennf

youennf Oct 23, 2018

I think it should be same-origin, depending on how we define the browsing context of this fetch request.

<ol>
<li><p>Set <var>request</var>'s <span data-x="concept-request-initiator">initiator</span>
to "prefetch".</p></li>
<li><p>Set <var>request</var>'s <span data-x="concept-request-keepalive-flag">keep-alive</span> flag

This comment has been minimized.

@youennf

youennf Oct 23, 2018

I was also wondering whether we should use keep alive or not.

My understanding so far is that keep alive has one context (the initial one) and when it goes away, it has no context.
This implies putting some restrictions on the number of keep alive requests. It also means we do not care about the response when context goes away.

For prefetch, the initial context is the same, but once it gets destroyed through navigation, we might either actually use the prefetch for the navigation task (hence using the response) or cancel it (navigating to some other URL).
This might be a different model with different restrictions.

This comment has been minimized.

@kinu

kinu Oct 26, 2018

If we add a text like 'the UA may abort the fetch if navigation happens to a different URL' could it work? Reusing response part could happen at cache level from impl pov but the part is not really spec'ed so it might be a bit tricky.

attribute.</p></li>
<li><p>Set <var>request</var>'s <span data-x="concept-request-destination">destination</span>
to the result of <span data-x="concept-potential-destination-translate">translating</span>
<var>as</var>.</p></li>

This comment has been minimized.

@youennf

youennf Oct 23, 2018

Are we sure 'as' will always be a valid destination? If not valid, are we ending up with the destination equal to the empty string?

This comment has been minimized.

@domfarolino

domfarolino Nov 26, 2018

Member

I think since as is an enumerated attribute, it can be in a conforming state and a non-conforming state, so we'll probably want a guard around it to make sure we only attempt translations on conforming states; see https://html.spec.whatwg.org/multipage/semantics.html#obtaining-a-resource-from-a-link-element:attr-link-rel

<li><p>Set <var>request</var>'s <span data-x="concept-request-destination">destination</span>
to the result of <span data-x="concept-potential-destination-translate">translating</span>
<var>as</var>.</p></li>
<li>If the browser is using both the <var>request</var>'s <span data-x="concept-request-url">URL</span> and the <span data-x="top-level-browsing-context">top-level browsing context</span>'s <span data-x="document">document</span>'s <var data-x="dom-document-origin">origin</span> as cache keys for <var>request</var>, then:

This comment has been minimized.

@youennf

youennf Oct 23, 2018

I believe this is the first introduction of that concept in web specs.
Should it be in fetch spec or somewhere else?
I understand 'cache keys' for request, fetch is referring to 'HTTP cache' so maybe HTTP should be made more explicit there?

<li><p>If <var>request</var>'s <span data-x="concept-request-destination">destination</span> is not "document", then return.</p></li>
<li><p>Set <var>request</var>'s <span data-x="concept-request-redirect-mode">redirect mode</span> to "manual".</p></li>
<li><p>Set <var>request</var>'s <span data-x="concept-request-redirect-mode">redirect mode</span> to "manual".</p></li>
<li><p>Set <var>request</var>'s <span data-x="concept-request-service-workers-mode">service workers mode</span> to "none".</p></li>

This comment has been minimized.

@kinu

kinu Oct 26, 2018

I wonder if we should just apply this regardless of the cache keys. (While it can be discussed separately)

<ol>
<li><p>Set <var>request</var>'s <span data-x="concept-request-initiator">initiator</span>
to "prefetch".</p></li>
<li><p>Set <var>request</var>'s <span data-x="concept-request-keepalive-flag">keep-alive</span> flag

This comment has been minimized.

@kinu

kinu Oct 26, 2018

If we add a text like 'the UA may abort the fetch if navigation happens to a different URL' could it work? Reusing response part could happen at cache level from impl pov but the part is not really spec'ed so it might be a bit tricky.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment