Re: RFC: draft-brown-device-stock-ua-00.txt

> The combination of client-hints and browser-hits seems extremely powerful
> and removes a lot of the guesswork that we have all adapted to.  In your
> proposal you mention the possibility of having a "well defined list of
> variable."  I think this is particularly important.  Best practice for
> extending these variable could leverage existing practices for HTTP headers
> or perhaps javascript API calls.
>

Yep. I'm explicitly limiting variables to what's currently already
available in the browser - don't want to get into the business of trying to
define new ones.


> Compression of this header (ideally in the context of general HTTP/2.0
> header compression) is vital for adoption, especially in the mobile context
> where every byte matters.
>

+1. Should have a new spec up soon which will, hopefully, address part of
this problem. The basic idea being that many of the variables are binary
(ex, WebGL on/off), which means that we can pack them very efficiently. The
tricky part is narrowing down the list of "continuos" variables like
viewport sizes, etc.

ig



>  From: Ilya Grigorik <ilya@igvita.com>
> Date: Friday, November 9, 2012 12:32 PM
> To: John Kemp <john@jkemp.net>
> Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
> Subject: Re: RFC: draft-brown-device-stock-ua-00.txt
> Resent-From: <ietf-http-wg@w3.org>
> Resent-Date: Friday, November 9, 2012 12:33 PM
>
>
>
> On Fri, Nov 9, 2012 at 11:33 AM, John Kemp <john@jkemp.net> wrote:
>
>> One question - what happens in the presence of an intermediary? SHOULD an
>> intermediary pass on the Client-hints HTTP header, if sent by a client?
>
>
> Yes. If the intermediary is the doing the adaptation based on the hint,
> then theoretically it could drop the header when forwarding the request
> (but more likely, just pass it along).
>
> ig
>
>