Subject: Re: Comments on httpbis-client-hints-01

From: Ilya Grigorik <[email-masked]>
Date: Wed, 1 Jun 2016 14:50:45 -0700

Hi Vasiliy.

Thanks for the feedback, here and on GitHub. WIP branch:
https://github.com/httpwg/http-extensions/pull/190

On Tue, May 31, 2016 at 11:15 AM, Vasiliy Faronov <[email-masked]>
wrote:

> Hi,
>
> A few comments on draft-ietf-httpbis-client-hints-01:
>
> 1. It seems to imply that Vary only includes the hints that were
> present in the request ("emit a Vary . . . to indicate which hints
> were used"). But, for example, if the request had *no* DPR field, yet
> the response *would* be influenced by a DPR field, shouldn't the
> response still include "Vary: DPR"?Otherwise a cache cannot know that
> a subsequent request with DPR must be written through to the origin
> server.
>

Good points, I think that makes sense. Any cache implementers / Vary
experts want to chime in here? What's the best practice to handle this?

> 2. The Accept-CH field seems underspecified. Is it per-resource? (and
> if so, doesn't it duplicate Vary?) Or is it per-origin? Or does it
> just apply to resources linked from the response?
>

If we're talking about browser as "client", then the behavior is specified
in Fetch API:
https://github.com/igrigorik/fetch/commit/1dd21259f4bbebfee21d89b0912559912284a60b

Does it duplicate Vary: no, I don't think so, they signal different things
to the client and they don't have same implications for upstream caches.

> 3. Are requirements like "If DPR occurs in a message more than once"
> (ditto for the other fields) useful? Duplicating these fields is
> already invalid per RFC 7230.
>

Ah, happy drop those if they're no longer needed. Any objections?

ig

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 3 Jun 2016 12:29:43 +1200

On 2/06/2016 9:50 a.m., Ilya Grigorik wrote:
> On Tue, May 31, 2016 at 11:15 AM, Vasiliy Faronov wrote:
> 
>> Hi,
>>

If the response is influenced by a header, then it needs to ('SHOULD')
be listed.

There is a case where some combination of the listed header values
results in a server actually not considerng the DPR at all for that
response. This shows up worst with Apache in the way its modules are
designed.

However, this is kind for coped with by the caches considering any
slight variation of the listed headers as a non-match for the specific
response(s) that exact Vary was handed back on. If a different set of
values for those same headers results in a DPR being added to the list
the cache has to alter its stored key and the previous set of variants
is "lost".

The "lost" factor leads to annoying headaches so best interoperability
would be to always list it. But the ecosystem can still cope with
servers that are not able to for some reason.

> Ah, happy drop those if they're no longer needed. Any objections?

The fact of being invalid is covered by 7230.

But how to handle these specific headers when invalid situations occur
is still needed in the more specific document.

Amos

---

From: Julian Reschke <[email-masked]>
Date: Fri, 3 Jun 2016 07:42:10 +0200

On 2016-06-03 02:29, Amos Jeffries wrote:
> ...
> ...

MUST, I think. But this doesn't need normative language here, just refer 
to the base spec.

> is still needed in the more specific document.

It's not strictly needed, but if you don't specify it, you'll likely 
cause implementors to make different decisions. That might be harmless 
for client hints, but it wasn't for other fields (such as Content-Length).

Best regards, Julian

---

From: Vasiliy Faronov <[email-masked]>
Date: Wed, 01 Jun 2016 22:46:50 +0000

Regarding Accept-CH: I was talking about the following text of the spec:

> When a client receives Accept-CH, it SHOULD append the Client Hint
> header fields that match the advertised field-values.  For example,
> based on Accept-CH example above, the client would append DPR, Width,
> Viewport-Width, and Downlink header fields to all subsequent
> requests.

This "all subsequent requests" is obviously intended to be qualified
somehow. It's not "all requests to all servers ever", is it? Should it
be "all subsequent requests to the same origin"? Should it be "all
subsequent requests to this resource"?

Likewise, the "SHOULD append" phrase is unclear: append to what exactly?

-- 
Vasiliy

---

From: Vasiliy Faronov <[email-masked]>
Date: Tue, 31 May 2016 18:16:06 +0000

Hi,

-- 
Vasiliy

---

From: Vasiliy Faronov <[email-masked]>
Date: Fri, 3 Jun 2016 14:26:08 +0300

> Ah, happy drop those if they're no longer needed. Any objections?

To expand on this:

I think many implementors will simply use whatever their platform's
equivalent of "request.headers['DPR']" gives them. For many (as in
WSGI/CGI), this will be all field-values joined by a comma. Those
requirements will make such implementations non-conformant--for no
good reason, it seems.

-- 
Vasiliy

---

From: Julian Reschke <[email-masked]>
Date: Fri, 3 Jun 2016 13:55:11 +0200

> requirements will make such implementations non-conformant--for no

But these implementations *could* split on comma and use the last value, 
right?

What would *you* want the spec to say? Just be silent about it? Or 
declare invalid therefore "must ignore"?

Best regards, Julian

---

From: Vasiliy Faronov <[email-masked]>
Date: Fri, 3 Jun 2016 15:11:29 +0300

On Fri, Jun 3, 2016 at 2:55 PM, Julian Reschke
<[email-masked]> wrote:
> What would *you* want the spec to say? Just be silent about it? Or declare
> invalid therefore "must ignore"?

Just be silent about it. Just as with other non-critical header
fields, such as User-Agent.

-- 
Vasiliy

---

From: Ilya Grigorik <[email-masked]>
Date: Fri, 3 Jun 2016 11:07:49 -0700

> Likewise, the "SHOULD append" phrase is unclear: append to what exactly?

We have a related open bug on GitHub, let's merge this discussion there:
https://github.com/httpwg/http-extensions/issues/189

> servers that are not able to for some reason.

Makes sense, thanks Amos.

s/which hints were used/which hints may affect the selected response/

Does that look reasonable?

> fields, such as User-Agent.

Define non-critical? Sadly, UA header is often used to make guesses about
client properties that then affect the selected response. One of the goals
of CH is to eliminate the need for such hacks and make this process
explicit.

I think we should keep the current language.

---

From: Vasiliy Faronov <[email-masked]>
Date: Sat, 4 Jun 2016 00:46:39 +0300

On Fri, Jun 3, 2016 at 9:07 PM, Ilya Grigorik <[email-masked]> wrote:
> Define non-critical?

One that doesn't have security implications, like Content-Length does.

I may be missing some context here: perhaps you have a specific idea
of who will be implementing this spec? I assumed it would be
interesting to a wide range of sites, and would be used by ordinary
Web developers. I don't think they will care about those details, so
you will end up with text that doesn't match the implementations.

However, I'm not an implementer, and this issue is not important to
me, so it's your call.

-- 
Vasiliy