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

As an intermediary/surrogate, this makes a lot of sense.  I can see the specific behavior required being very situational.

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.

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.

-stephen

From: Ilya Grigorik <ilya@igvita.com<mailto:ilya@igvita.com>>
Date: Friday, November 9, 2012 12:32 PM
To: John Kemp <john@jkemp.net<mailto:john@jkemp.net>>
Cc: "ietf-http-wg@w3.org<mailto:ietf-http-wg@w3.org>" <ietf-http-wg@w3.org<mailto:ietf-http-wg@w3.org>>
Subject: Re: RFC: draft-brown-device-stock-ua-00.txt
Resent-From: <ietf-http-wg@w3.org<mailto: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<mailto: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