Integrate Client-Hints with Fetch #258

igrigorik · 2016-03-22T17:14:36Z

Last-Event-ID is defined in the HTML spec as a utf-8 string, hence we
don't place any restrictions on its value
Each Client Hints header has a BNF grammar that should be validated by
the user agent; the header is defined as simple if the name of the
header matches one of CH header names, and its value conforms to the
defined grammar

Closes:

annevk · 2016-03-22T17:21:13Z

Overview.src.html

+  `<code title><a href=http://httpwg.org/http-extensions/client-hints.html#the-downlink-client-hint>Downlink</a></code>`,
+  `<code title><a href=http://httpwg.org/http-extensions/client-hints.html#the-save-data-hint>Save-Data</a></code>`,
+  `<code title><a href=http://httpwg.org/http-extensions/client-hints.html#the-viewport-width-client-hint>Viewport-Width</a></code>`, or
+  `<code title><a href=http://httpwg.org/http-extensions/client-hints.html#the-width-client-hint>Width</a></code>`, and whose value, once parsed, is not a failure.


value and once parsed need to be cross-referenced.

Ack, updated.

annevk · 2016-03-22T17:22:48Z

I have some concerns here:

Where did this get security review?
Note that in [EventSource] Is Last-Event-ID header value allowed to contain any-char? html#689 we might change the value space of Last-Event-ID.
According to dev.platform the Client-Hints headers are still controversial. Are there any user agents other than Chromium shipping these?

igrigorik · 2016-03-22T18:27:40Z

Where did this get security review?

For Client Hints, we went through a privacy and security review as part of our intent to ship; same for Save-Data.

Note that in whatwg/html#689 we might change the value space of Last-Event-ID.

Ah, that makes sense. I'm happy to drop Last-Event-ID from this pull until that's resolved.

According to dev.platform the Client-Hints headers are still controversial. Are there any user agents other than Chromium shipping these?

Chrome and Opera supports Width, Viewport-Width, DPR, Save-Data. Yandex is shipping Save-Data. Edge has it listed as under consideration.

annevk · 2016-03-23T08:03:34Z

Okay, so other than Chromium there's no other engines yet. That's a bit of a concern. It'd be better if one of Mozilla, Apple, or Microsoft expressed support.

Should we expand the scope of this PR to include httpwg/http-extensions#156?

And yeah, doing Last-Event-ID separately seems better.

igrigorik · 2016-03-30T23:09:45Z

Dropped Last-Event-ID and took a first run at integrating the proposed logic in httpwg/http-extensions#156 (comment) with Fetch. I'm sure it's rough around the edges, let me know if I'm heading in the right direction.

annevk · 2016-03-31T08:56:17Z

Overview.src.html

+  `<code title><a href=http://httpwg.org/http-extensions/client-hints.html#the-viewport-width-client-hint>Viewport-Width</a></code>`, or
+  `<code title><a href=http://httpwg.org/http-extensions/client-hints.html#the-width-client-hint>Width</a></code>`, and whose <span title=concept-header-value>value</span>,
+  <span title=concept-header-parse>once parsed</span>, is not a failure.
+</ul>


I think it might be better to have or whose name is one of <ul class=brief> ... </ul> and value, once parsed, is not failure. after the Content-Type entry. It seems a little weird to have a list of header names and then have a list of header names inside that list.

igrigorik · 2016-04-01T15:36:06Z

@annevk thanks for the review! Updated the pull -- ptal.

annevk · 2016-04-01T16:10:59Z

Overview.src.html

+
+<p>A <dfn title=concept-client-hints-list>client hints list</dfn> is a list of
+<a href=http://httpwg.org/http-extensions/client-hints.html#rfc.section.2.2.1>Client hint tokens</a>,
+which is one of `<code title>dpr</code>`, `<code title>save-data</code>`,


I guess this should say "each of which". Otherwise it reads as if the list is a byte sequence.

annevk · 2016-04-01T16:23:00Z

Also, the URLs you use don't really give information on the value. And don't use HTTPS.

igrigorik · 2016-04-01T17:08:09Z

Updated to use a table and fixed the links (good catch!). Hopefully we're getting closer :)

/cc @mnot https://httpwg.org is timing out for me. Is that a known issue?

annevk · 2016-04-01T17:34:48Z

The URL fragments seem incorrect. You hyphenate the section titles but the fragment is actually shorter.
Those sections, in your draft, should probably say they define the header field value. A header field consists of a name and a value.
Rather than referencing them as "definition" it would be clearer to use a suitable <a><code>Width</code> value</a> or some such.

annevk · 2016-04-01T17:38:01Z

If you could also patch https://github.com/whatwg/xref to add the new reference that'd be great. I'll help out a bit with the final formatting once most is in shape. And yeah, I think it's pretty close.

igrigorik · 2016-04-01T18:25:25Z

The URL fragments seem incorrect. You hyphenate the section titles but the fragment is actually shorter.

Oi.. Not sure what happened there. Pushed a fix.

Those sections, in your draft, should probably say they define the header field value. A header field consists of a name and a value.

Sounds reasonable, I'll take that as a separate AI.

Rather than referencing them as "definition" it would be clearer to use a suitable Width value or some such.

Replaced "definition" with "suitable value", which links to the definition. Does that look better? I didn't want to repeat the header name.

Re, xref: whatwg/xref#10

Do you want me to squash the changes?

annevk · 2016-04-03T13:31:13Z

The problem with not repeating the name of the header (though technically you'd be giving the name of the value production, not the header name) is that then you have six or so links that have an identical name. That is terrible UX for people with screen readers.

annevk · 2016-04-03T13:31:55Z

I'll take that as a separate AI

Not sure I understood, should I file an issue somewhere?

igrigorik · 2016-04-04T17:57:49Z

The problem with not repeating the name of the header (though technically you'd be giving the name of the value production, not the header name) is that then you have six or so links that have an identical name. That is terrible UX for people with screen readers.

Ah, that's fair. Updated.

Not sure I understood, should I file an issue somewhere?

I'll tackle it as part of httpwg/http-extensions#156 (comment).

Anything else left?

annevk · 2016-04-05T07:50:43Z

Overview.src.html

+  `<code title><a href=http://httpwg.org/http-extensions/client-hints.html#downlink>Downlink</a></code>`,
+  `<code title><a href=http://httpwg.org/http-extensions/client-hints.html#save-data>Save-Data</a></code>`,
+  `<code title><a href=http://httpwg.org/http-extensions/client-hints.html#viewport-width>Viewport-Width</a></code>`, or
+  `<code title><a href=http://httpwg.org/http-extensions/client-hints.html#width>Width</a></code>`


These should all have their own <li>.

Having said that, I would be okay with taking your text, modifying it a bit to match existing editorial style, and then committing it (with you still listed as author of course). The only downside of that is that this PR will be red, not purple. If that is a concern, I'll continue nitpicking a bit.

igrigorik · 2016-04-05T17:25:02Z

@annevk split the long list into separate li's and squashed the commits. In terms of next steps: whichever is easier for you. I'm happy to continue updating, or you can take it and run with it.. the "color" on the PR doesn't bother me :)

update: rebased to resolve conflicts.

annevk · 2016-04-06T07:36:24Z

Overview.src.html

+
+<p class="note no-backref">This can be used to override a client hints list associated with
+an <span data-anolis-spec=html>environment settings object</span>.
+<span data-anolis-ref>CLIENT-HINTS</span>


CLIENT-HINTS doesn't define a client hints list associated with an environment settings object. What exactly is the purpose of this?

Right, that part hasn't been specced yet. My intent is to mirror similar language as referrer policy.

We can either do that within the CH draft.

Or, we can integrate that language directly into the HTML spec?

Any preference on one vs other? /cc @mnot

Not really, as long as it's clearly defined. I guess it would be good to state in the note that this is not yet defined. Or say "will be used" or some such. Then we can update it later once things are defined.

igrigorik · 2016-04-06T18:09:28Z

@annevk ack on formatting, see 1185bc1.

annevk · 2016-04-07T08:56:20Z

Overview.src.html

+<a href=http://httpwg.org/http-extensions/client-hints.html#accept-ch>Client hint tokens</a>,
+each of which is one of `<code title>dpr</code>`,
+`<code title>save-data</code>`, `<code title>viewport-width</code>`, or
+`<code title>width</code>`.


It might make sense to define this concept ("client hints list") directly in CLIENT-HINTS too, especially if it is going to be reused by multiple concepts.

Seems reasonable. Do you want me to drop this from here then? Or, should we remove this and add a reference once we have the other bits specc'ed in CH/HTML spec.

Either way is fine with me. If you want to go with the former approach I'd appreciate you adding  after this .

igrigorik · 2016-04-07T17:44:01Z

@annevk ack on formatting, ptal.

Also, as an aside: it'd be great to have a section in the readme, or a standalone doc, with formatting conventions.

annevk · 2016-04-08T04:48:00Z

Thanks for mentioning that. I created https://gist.github.com/annevk/2f51a1082850a2814204a9a8a07f9654 as a start. What do you think? It's not entirely clear to me yet where to best host it, since these guidelines are shared across many repositories, but maybe here is fine in a FORMATTING.md file and then the other repositories can point to it. (whatwg/html will need a slightly different one that I can also write I suppose.) @domenic @foolip thoughts?

domenic · 2016-04-08T05:06:57Z

Seems OK for DOM and partially for HTML. You should probably also mention your preferences on end tag omission and attribute quoting omission.

I don't think any of those guidelines apply to streams, e.g. there we use 120 chars and Markdown-style lists (in both Bikeshed and with the Ecmarkup integration). So probably introduce this on a repository-by-repository basis.

foolip · 2016-04-08T09:23:02Z

I suppose we'll need one style for HTML and one for all other WHATWG specs? Media Session uses 80 columns, FWIW.

Also, the 'Do not use newlines inside "inline" elements' rule seems weird, that's not what we do in HTML.

annevk · 2016-04-08T10:34:16Z

Yeah, I figure we need multiple for now. Was just wondering about reuse but I suppose specifications that reuse can point at each other their policy just as we do now.

- DPR, Save-Data, Viewport-Width are sent on navigation requests - Subresource requests are subject to the set client hints policy - Client Hints headers are treated as simple headers: each Client Hints heaer has a BNF grammar that should be validated bythe user agent. Closes: - whatwg#52 - httpwg/http-extensions#141

igrigorik · 2016-04-08T20:29:49Z

@annevk added the XXX/TODO and squashed -- think it should be good to go!

Re, gist: yes, that's exactly what I was looking for. Now, if only we could coerce tidy into automating this for us... that would be super.

annevk · 2016-04-10T14:41:25Z

I landed this as 404dc3a. Purple PR was not possible anyway due to Overview.html not being generated.

I changed the XXX comment to a note and moved it to a more appropriate place.

igrigorik · 2016-04-10T18:34:56Z

👍 looks great, thanks Anne!

annevk reviewed Mar 22, 2016
View reviewed changes

igrigorik mentioned this pull request Mar 23, 2016

Define more precisely which CH headers are sent by default httpwg/http-extensions#156

Closed

igrigorik changed the title ~~Treat Last-Event-ID and Client-Hints headers as simple headers~~ Integrate Client-Hints with Fetch Mar 30, 2016

annevk reviewed Mar 31, 2016
View reviewed changes

annevk reviewed Apr 1, 2016
View reviewed changes

annevk reviewed Apr 5, 2016
View reviewed changes

igrigorik force-pushed the ua-set-headers branch from 43520e2 to 1dd2125 Compare April 5, 2016 17:23

igrigorik force-pushed the ua-set-headers branch from 1dd2125 to 24aead4 Compare April 5, 2016 17:37

annevk reviewed Apr 6, 2016
View reviewed changes

annevk reviewed Apr 7, 2016
View reviewed changes

igrigorik force-pushed the ua-set-headers branch from 61cb503 to e636e01 Compare April 8, 2016 20:28

This was referenced Apr 10, 2016

Write a formatting guide #276

Closed

Rename simple header #277

Closed

annevk closed this Apr 10, 2016

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Integrate Client-Hints with Fetch #258

Integrate Client-Hints with Fetch #258

igrigorik commented Mar 22, 2016

annevk Mar 22, 2016

igrigorik Mar 22, 2016

annevk commented Mar 22, 2016

igrigorik commented Mar 22, 2016

annevk commented Mar 23, 2016

igrigorik commented Mar 30, 2016

annevk Mar 31, 2016

igrigorik commented Apr 1, 2016

annevk Apr 1, 2016

annevk commented Apr 1, 2016

igrigorik commented Apr 1, 2016

annevk commented Apr 1, 2016

annevk commented Apr 1, 2016

igrigorik commented Apr 1, 2016

annevk commented Apr 3, 2016

annevk commented Apr 3, 2016

igrigorik commented Apr 4, 2016

annevk Apr 5, 2016

igrigorik commented Apr 5, 2016

annevk Apr 6, 2016

igrigorik Apr 6, 2016

annevk Apr 7, 2016

igrigorik commented Apr 6, 2016

annevk Apr 7, 2016

igrigorik Apr 7, 2016

annevk Apr 8, 2016

igrigorik commented Apr 7, 2016

annevk commented Apr 8, 2016

domenic commented Apr 8, 2016

foolip commented Apr 8, 2016

annevk commented Apr 8, 2016

igrigorik commented Apr 8, 2016

annevk commented Apr 10, 2016

igrigorik commented Apr 10, 2016

Integrate Client-Hints with Fetch #258

Integrate Client-Hints with Fetch #258

Conversation

igrigorik commented Mar 22, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

annevk commented Mar 22, 2016

igrigorik commented Mar 22, 2016

annevk commented Mar 23, 2016

igrigorik commented Mar 30, 2016

Choose a reason for hiding this comment

igrigorik commented Apr 1, 2016

Choose a reason for hiding this comment

annevk commented Apr 1, 2016

igrigorik commented Apr 1, 2016

annevk commented Apr 1, 2016

annevk commented Apr 1, 2016

igrigorik commented Apr 1, 2016

annevk commented Apr 3, 2016

annevk commented Apr 3, 2016

igrigorik commented Apr 4, 2016

Choose a reason for hiding this comment

igrigorik commented Apr 5, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

igrigorik commented Apr 6, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

igrigorik commented Apr 7, 2016

annevk commented Apr 8, 2016

domenic commented Apr 8, 2016

foolip commented Apr 8, 2016

annevk commented Apr 8, 2016

igrigorik commented Apr 8, 2016

annevk commented Apr 10, 2016

igrigorik commented Apr 10, 2016