Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Check Feature Policy before attaching Client Hints #811

Closed
wants to merge 2 commits into from
Closed

Check Feature Policy before attaching Client Hints #811

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
2f20316
Check Feature Policy before sending Client Hints
eeeps Sep 24, 2018
8760549
Add Feature-Policy biblio reference
eeeps Sep 24, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
19 changes: 17 additions & 2 deletions fetch.bs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -86,6 +86,14 @@ url:https://tools.ietf.org/html/rfc7234#section-1.2.1;text:delta-seconds;type:df
},
"OCSP": {
"aliasOf": "RFC2560"
},
"FEATURE-POLICY": {
"authors": [
"Ian Clelland"
],
"href": "https://wicg.github.io/feature-policy/",
"publisher": "WICG",
"title": "Feature Policy"
}
}
</pre>
Expand Down Expand Up @@ -2813,8 +2821,15 @@ the request.
<dd>a suitable <a href=http://httpwg.org/http-extensions/client-hints.html#width>width value</a>
</dl>

<li><p>A user agent should <a for="header list">append</a>
<var>hintName</var>/<var>value</var> to <var>request</var>'s <a for=request>header list</a>.
<li><p>If the result of running
<a href="https://wicg.github.io/feature-policy/#should-request-be-allowed-to-use-feature">Should
<var>request</var> be allowed to use <var>feature</var>?</a>,
given <var>request</var> and <var>hintName</var>’s
<a href="http://httpwg.org/http-extensions/client-hints.html#opt-in-via-feature-policy">associated
policy-controlled feature</a>, returns <code>true</code>, the user agent should
<a for="header list">append</a> <var>hintName</var>/<var>value</var> to <var>request</var>'s
<a for=request>header list</a>.
[[!FEATURE-POLICY]] [[!CLIENT-HINTS]]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some existing plumbing that we need to refactor:

I think the behavior we want here is..

  1. We need to define the Accept-CH opt-in processing in HTML spec
  2. For nav request, update Fetch to reference (1) instead of current "client hints tokens" ref to IETF spec
  3. For subresources, execute algorithm defined in FP, checking for delegation

@eeeps @annevk WDYT, does that make sense?

Copy link
Collaborator

@yoavweiss yoavweiss Oct 1, 2018 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(1) and (2) are implemented (but not yet landed) in whatwg/html#3774 and #773

@eeeps & @tarunban - maybe we should merge all the different CH related PRs, to make it easier to discuss them in a holistic manner. Thoughts?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I'd much prefer we don't add feature policy until the architecture is more correctly described.

</ol>

<li><p>Let <var>record</var> be a new
Expand Down