Re: New Version Notification for draft-nottingham-variants-01.txt

On 2017-10-31 00:08, Mark Nottingham wrote:
> On 30 Oct 2017, at 10:13 pm, Julian Reschke <julian.reschke@gmx.de> wrote:
>>
>> On 2017-10-30 05:41, Mark Nottingham wrote:
>>> FYI, an update of Variants.
>>> This one removes the requirement for conneg mechanisms to identify their own response header ("Content-*"), in favour of a central one -- Variant-Key.
>>> Doing so avoids the big problem with Variants-00, where the semantics of a header like Content-Encoding could clash with variants' needs.
>>> So, you now have a response that looks something like:
>>> Vary: Accept-Encoding, Accept-Language
>>> Variants: Accept-Encoding;gzip;br, Accept-Language;fr;en;jp
>>> Variant-Key: gzip,en
>>> ... which roughly translates to "There are gzip, brotli and identity representations of this resource, in French, English and Japanese; THIS representation is the gzip'd English one."
>>> ...
>>
>>
>> Looking at the examples, they seem a bit chatty. Can't we collapse this into a single field, like:
>>
>> Variants: Accept-Encoding;available="gzip br";selected=gzip, Accept-Language;available="fr en jp";selected=en
>>
>> ? (and yes, we could abbreviate the parameter names).
> 
> I considered that, but it seems like making them separate will make at least the Variants header (in the current design) more likely to get a hit in HPACK. (...)

Just checking: that's mainly true when multiple UAs share the same 
connection, right? For a single UA, I would assume that during normal 
operation, most of the time the same variant would be selected, so 
inlining the "selected" information wouldn't hurt...

Best regards, Julian

Received on Tuesday, 31 October 2017 11:14:28 UTC