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.

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

Client hints updates #4907

Merged
merged 8 commits into from
Jun 1, 2021
Merged

Client hints updates #4907

merged 8 commits into from
Jun 1, 2021

Conversation

hamishwillee
Copy link
Collaborator

@hamishwillee hamishwillee commented May 11, 2021

Partially fixes #1408

This does lots of other tidy up around the area and fixes part of the problem. But will do new additions as a post process.

@github-actions
Copy link
Contributor

github-actions bot commented May 11, 2021

Preview URLs

Flaws

Note! 8 documents with no flaws that don't need to be listed. 🎉

URL: /en-US/docs/Web/HTTP/Headers
Title: HTTP headers
on GitHub
Flaw count: 3

  • macros:
    • /en-US/docs/Glossary/COEP does not exist
    • /en-US/docs/Glossary/COOP does not exist
    • /en-US/docs/Glossary/CORP does not exist

URL: /en-US/docs/Web/HTTP/Headers/Feature-Policy
Title: Feature-Policy
on GitHub
Flaw count: 2

  • macros:
    • /en-US/docs/Web/API/Navigator/requestMIDIAccess does not exist
  • broken_links:
    • Can't resolve /en-US/docs/Web/API/Web_MIDI_API

External URLs

URL: /en-US/docs/Web/HTTP/Headers
Title: HTTP headers
on GitHub

No new external URLs


URL: /en-US/docs/Web/HTTP/Headers/DPR
Title: DPR
on GitHub

No new external URLs


URL: /en-US/docs/Web/HTTP/Headers/Device-Memory
Title: Device-Memory
on GitHub

No new external URLs


URL: /en-US/docs/Web/HTTP/Headers/Accept-CH-Lifetime
Title: Accept-CH-Lifetime
on GitHub

No new external URLs


URL: /en-US/docs/Web/HTTP/Headers/Accept-CH
Title: Accept-CH
on GitHub

No new external URLs


URL: /en-US/docs/Web/HTTP/Headers/Save-Data
Title: Save-Data
on GitHub

No new external URLs


URL: /en-US/docs/Web/HTTP/Headers/Feature-Policy
Title: Feature-Policy
on GitHub


URL: /en-US/docs/Web/HTTP/Headers/Early-Data
Title: Early-Data
on GitHub

No new external URLs


URL: /en-US/docs/Glossary/Forbidden_header_name
Title: Forbidden header name
on GitHub


URL: /en-US/docs/Glossary/Client_hints
Title: Client hints
on GitHub

(this comment was updated 2021-06-01 07:25:45.405476)

---
<div>{{HTTPSidebar}}{{securecontext_header}}{{Deprecated_header}}{{Non-standard_header}}</div>
<div>{{HTTPSidebar}}{{securecontext_header}}{{Deprecated_header}}</div>
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Note, this is non-standard. Last time I had both that and a deprecated header Chris suggested the deprecated header along covers that you should not use it.

@@ -26,7 +26,7 @@
<li><code>Date</code></li>
<li><code>DNT</code></li>
<li><code>Expect</code></li>
<li><code>Feature-Policy</code></li>
<li><code>Feature-Policy</code></li>
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@Elchi3 How does one find out if something is a forbidden header name? Specifically, I checked the Fetch spec, and it matches the list here except it does not mention Feature-Policy. So how would I find out that Feature Policy is forbidden (I searched on forbidden in the permission-policy spec too and the term does not appear).

The main reason I ask is that the client hints all have "?" in the table for forbidden, so would help me to understand how you confirm their status.

Further, w.r.t. this doc, should I also add Permission-Policy?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Actually it's Permissions-Policy with an 's'.

Copy link
Member

Choose a reason for hiding this comment

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

I thought the list from the Fetch spec is exhaustive and new forbidden headers would start with Sec- but maybe that is a misunderstanding from my side.

I previously only confirmed these by looking at the Fetch spec...

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Thanks @Elchi3. The fetch spec being exhaustive seems a reasonable assumption. Just wasn't one I wanted to make. Happy to go with that now.

I wont add Permissions-Policy because I now know that this will be done "all in one go" later on.

@hamishwillee
Copy link
Collaborator Author

Hi @Elchi3
I'm trying to work out if we have missed any Client hint headers in docs.

We already document these headers:

  • Device-Memory
  • Viewport-Width
  • Width
  • Save-Data
    • Note, need to add that this is a low entropy hint (ie one that will likely be sent even if not requested using Accept-CH).
    • Note, need to document what low entropy hints are.
  • (Deprecated and not in the spec) Accept-CH-Lifetime
  • (Deprecated BCD and is in the current spec DPR)

I think we are missing these (do you know of any reason not to include them)?:

  • Viewport-Height
  • RTT
  • Downlink
  • ECT

Further there are a bunch of new User Agent Client Hints. These are defined in a "Draft Community Group Report, 4 May 2021" (i.e. not a standards track thingy yet). I haven't done a full check but at least some of these are implemented in chrome 90 (and not yet in firefox https://bugzilla.mozilla.org/show_bug.cgi?id=935216#c67). What is our position on documenting these? (i.e. "do we document these"?):

  • Sec-CH-UA - low entropy hint.
  • Sec-CH-UA-Arch
  • Sec-CH-UA-Bitness
  • Sec-CH-UA-Full-Version
  • Sec-CH-UA-Mobile - low entropy hint.
  • Sec-CH-UA-Model
  • Sec-CH-UA-Platform - low entropy hint.
  • Sec-CH-UA-Platform-Version

Are there any others you know of?

Last of all, can you please review and merge this if it is OK? I'd like to do follow on fixes with bumping against other work people are doing :-)

@hamishwillee hamishwillee marked this pull request as ready for review May 21, 2021 06:32
@hamishwillee hamishwillee requested review from a team as code owners May 21, 2021 06:32
@hamishwillee hamishwillee requested review from chrisdavidmills and removed request for a team May 21, 2021 06:32
@chrisdavidmills chrisdavidmills requested review from Elchi3 and removed request for chrisdavidmills May 21, 2021 07:19
@chrisdavidmills
Copy link
Contributor

Seems that @Elchi3 is a better choice of official reviewer for this one.

@hamishwillee
Copy link
Collaborator Author

@Elchi3 (or @chrisdavidmills ) do you think you might have time to look at this today? Then I can continue the work tomorrow :-)

@Elchi3
Copy link
Member

Elchi3 commented May 27, 2021

Sorry Hamish, I will try to get to it but probably not this week.

@hamishwillee
Copy link
Collaborator Author

@Elchi3 Thank you - just wanted to make sure this was on your radar. Plenty to go on with :-)

FWIW An answer to the question above in #4907 (comment) is more useful than an actual review of the PR, as it would unblock me.

@Elchi3
Copy link
Member

Elchi3 commented May 31, 2021

I think we are missing these (do you know of any reason not to include them)?:

  • Viewport-Height
  • RTT
  • Downlink
  • ECT

These look good to me, although I'm not sure there is a (somewhat stable) specification for Viewport-Height. Maybe leave this out for now? (or maybe I'm missing something, pointers to specs appreciated).

What is our position on documenting these? (i.e. "do we document these"?):

  • Sec-CH-UA - low entropy hint.
  • Sec-CH-UA-Arch
  • Sec-CH-UA-Bitness
  • Sec-CH-UA-Full-Version
  • Sec-CH-UA-Mobile - low entropy hint.
  • Sec-CH-UA-Model
  • Sec-CH-UA-Platform - low entropy hint.
  • Sec-CH-UA-Platform-Version

Not sure who "ours" is in "our position". Mozilla thinks is it "non-harmful" in https://mozilla.github.io/standards-positions/
My feeling is we could document this now but maybe check what you know against https://developer.mozilla.org/en-US/docs/MDN/Guidelines/Conventions_definitions#when_to_document_new_technologies?

Are there any others you know of?

There seem to be quite a few Client hints specs but it looks like you got the main ones here. Of course things are always in flux...

Copy link
Member

@Elchi3 Elchi3 left a comment

Choose a reason for hiding this comment

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

Thanks for the PR! Some nits but LGTM otherwise

files/en-us/glossary/client_hints/index.html Outdated Show resolved Hide resolved
files/en-us/glossary/client_hints/index.html Outdated Show resolved Hide resolved
- Deprecated
- Non-standard
- Exerimental
Copy link
Member

Choose a reason for hiding this comment

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

Deprecated, non-standard, experimental? What is going on here?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@Elchi3 This is a reflection of the BCD.
image

Previously experimental was omitted - so all I did was add the tag as well (this updates the sidebar with the icon).

@@ -81,12 +81,12 @@ <h2 id="Client_hints">Client hints</h2>
<dl>
<dt>{{HTTPHeader("Accept-CH")}} {{experimental_inline}}</dt>
<dd>Servers can advertise support for Client Hints using the <code>Accept-CH</code> header field or an equivalent HTML <code>&lt;meta&gt;</code> element with <code>http-equiv</code> attribute (<a href="https://html.spec.whatwg.org/multipage/semantics.html#attr-meta-http-equiv"><cite>[HTML]</cite></a>).</dd>
<dt>{{HTTPHeader("Accept-CH-Lifetime")}} {{experimental_inline}}</dt>
<dt>{{HTTPHeader("Accept-CH-Lifetime")}} {{experimental_inline}} {{deprecated_inline}}</dt>
Copy link
Member

Choose a reason for hiding this comment

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

No longer experimental?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@Elchi3 Still experimental but also deprecated.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

For all of these I matched the docs to BCD. Note that arguably for page headers you only need one of these - the deprecated. But since I can't find a clear policy on that I haven't removed the other headers. I have been trying to discuss/get agreement on that in the context of auto-generation of headers from BCD.

Copy link
Member

Choose a reason for hiding this comment

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

Thanks for matching BCD, let's go with this then.

Co-authored-by: Florian Scholz <fs@florianscholz.com>
@hamishwillee
Copy link
Collaborator Author

@Elchi3 I think I've either merged or answered your nits, and also fixed the conflicts.

Thanks very much for the info on which headers to document. That will come as follow on.

Copy link
Member

@Elchi3 Elchi3 left a comment

Choose a reason for hiding this comment

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

Thanks Hamish! 🎉

@Elchi3 Elchi3 merged commit 7a06a72 into mdn:main Jun 1, 2021
@hamishwillee hamishwillee deleted the http_accept-ch branch June 1, 2021 08:38
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Aug 8, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Incomplete information for Accept-CH page
4 participants