Define preconnect and dns-prefetch with CSP#1620
Conversation
annevk
left a comment
There was a problem hiding this comment.
It's unfortunate these have to be separate algorithms. I was hoping we could do CSP checks as part of the normal "obtain a connection" routine.
We can do that but then there would be double CSP checks, one for the request and one for the "fake" request, or we can add a flag to obtain/resolve of whether to perform the CSP check. |
fetch.bs
Outdated
| and <a href="https://en.wikipedia.org/wiki/Proxy_auto-config">proxy auto-config (PAC)</a> come | ||
| into play. The "<code>DIRECT</code>" value means to not use a proxy for this particular | ||
| <var>url</var>. | ||
| <li><p>Let <var>proxies</var> of calling <a>resolve proxies</a>. |
There was a problem hiding this comment.
What words are missing? The note was moved to resolve proxies.
fetch.bs
Outdated
| <p>To <dfn>resolve proxies</dfn>, return the result of finding proxies for <var>url</var> in an | ||
| <a>implementation-defined</a> manner. If there are no proxies, return « "<code>DIRECT</code>" ». |
There was a problem hiding this comment.
Where does url come from here? If it needs to be an argument, let's make it explicit.
fetch.bs
Outdated
|
|
||
| <h3 id=preemptive-connections>Preemptive connections</h3> | ||
|
|
||
| <div algorithm="preemmptively-obtain-a-connection"> |
There was a problem hiding this comment.
Does algorithm need this value? Normally it works without.
fetch.bs
Outdated
| <p><a>Check CSP for preemptive operation</a> with <var>environment</var> and <var>url</var>. If | ||
| that returns <b>allowed</b>, <a>obtain a connection</a> with <var>key</var>, <var>url</var> and | ||
| <var>credentials</var>. |
fetch.bs
Outdated
| <div algorithm="check-preemptive-operation-csp"> | ||
| <p>To <dfn>check CSP for preemptive operation</dfn>, given an | ||
| <a>environment settings object</a> <var>environment</var>, and a <a for=/>URL</a> <var>url</var>, | ||
| run these steps: |
There was a problem hiding this comment.
Perhaps this can have a more descriptive name such as "does CSP allow a connection" and we normalize the return value from CSP to true/false while we're here.
Seems this went unaddressed?
fetch.bs
Outdated
| </ol> | ||
| </div> | ||
|
|
||
| <div algorithm="check-preemptive-operation-csp"> |
There was a problem hiding this comment.
This attribute value isn't needed.
fetch.bs
Outdated
| </ol> | ||
| </div> | ||
|
|
||
| <div> |
There was a problem hiding this comment.
This needs an algorithm attribute.
fetch.bs
Outdated
| </div> | ||
|
|
||
| <div algorithm="check-preemptive-operation-csp"> | ||
| <p>To <dfn>Should connection be allowed by Content Security Policy?</dfn>, given an |
There was a problem hiding this comment.
This algorithm needs a better name. E.g., "determine if Content Security allows connection". The name shouldn't have a question mark and should read naturally after "To" if you're using to to lead it in.
fetch.bs
Outdated
| <div algorithm="check-preemptive-operation-csp"> | ||
| <p>To <dfn>Should connection be allowed by Content Security Policy?</dfn>, given an | ||
| <a>environment settings object</a> <var>environment</var>, and a <a for=/>URL</a> <var>url</var>, | ||
| run these steps: |
There was a problem hiding this comment.
No need for "run these steps" when you lead it in with "To".
fetch.bs
Outdated
| <li><p>Return the result of running <a>should request be blocked by Content Security Policy?</a> | ||
| given <var>request</var>. |
There was a problem hiding this comment.
We should put the result in a variable first and then convert that to a boolean.
Co-authored-by: Valentin Gosu <[email protected]>
Co-authored-by: Anne van Kesteren <[email protected]>
Co-authored-by: Anne van Kesteren <[email protected]>
annevk
left a comment
There was a problem hiding this comment.
Apologies for the delay here. Found a couple more issues to address.
| <p class=note>The user agent can attempt to initiate a preconnect and perform the full | ||
| connection handshake (DNS+TCP for HTTP, and DNS+TCP+TLS for HTTPS origins) whenever possible, but | ||
| is allowed to elect to perform a partial handshake (DNS only for HTTP, and DNS or DNS+TCP for | ||
| HTTPS origins), or skip it entirely, due to resource constraints or other reasons.</p> | ||
|
|
||
| <p class=note>The optimal number of connections per origin is dependent on the negotiated | ||
| protocol, users current connectivity profile, available device resources, global connection | ||
| limits, and other context specific variables. As a result, the decision for how many connections | ||
| should be opened is deferred to the user agent.</p> |
There was a problem hiding this comment.
These notes feel like normative material. One even contains "should"! In the step above where we obtain the connection perhaps we should have a "with these caveats" ending that then leads into some bullet points?
Co-authored-by: Anne van Kesteren <[email protected]>
Co-authored-by: Anne van Kesteren <[email protected]>
Preconnect & dns-prefetch test a fake prefetch request for CSP, and then obtain a connection/resolve an origin.
See whatwg/html#9035
(See WHATWG Working Mode: Changes for more details.)
Preview | Diff